From nobody Tue Dec 1 02:38: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 4638A3A10CD for ; Tue, 1 Dec 2020 02:38:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.421 X-Spam-Level: X-Spam-Status: No, score=-4.421 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_MED=-2.3, 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 bKsjfpy3gDc1 for ; Tue, 1 Dec 2020 02:37:58 -0800 (PST) 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 5D1623A10CC for ; Tue, 1 Dec 2020 02:37:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1606819075; bh=HBwoI3ZVUDVIVWGkPhVhb0hrIlJyYoe6h0oSfF0BkMU=; l=3350; h=To:Cc:References:From:Date:In-Reply-To; b=BHw12sE3w4XIP+LkuQdwcIeP+TOcH6GIwH8DPzak/B8kUmX4vaOXmaBXdrV/e7lQQ AEL81rTCJJoiriFflx+DY/QDQoH+qq7HfV6B9rFVdwELiPpQG0i83k9KGFR5pVKa4A Kk8CzHVhx278r03uJtKqXI9flMiach0ewRs4artjS2f1JlAr76QB9q/RWSPMh Authentication-Results: tana.it; auth=pass (details omitted) Original-From: Alessandro Vesely Original-Cc: IETF DMARC WG 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 00000000005DC02A.000000005FC61D03.00002FEE; Tue, 01 Dec 2020 11:37:55 +0100 To: Brandon Long Cc: IETF DMARC WG References: <8c83fffc-077d-9ddb-db2f-b9763361c60f@tana.it> <39eafc5e-3d9c-0bea-1173-7277070195ea@wisc.edu> <081c42a3-492b-89b7-ad76-ccec48dea091@tana.it> <2d1dca4f-e46a-646c-9fa3-d9ca56c72196@tana.it> From: Alessandro Vesely Message-ID: Date: Tue, 1 Dec 2020 11:37:54 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] A policy for direct mail flows only, was ARC questions X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 01 Dec 2020 10:38:00 -0000 On Tue 01/Dec/2020 05:56:46 +0100 Brandon Long wrote: > On Thu, Nov 26, 2020 at 12:59 AM Alessandro Vesely wrote: > >> On 25/11/2020 20:16, Michael Thomas wrote: >>> On 11/25/20 11:11 AM, Alessandro Vesely wrote: >>>> On 25/11/2020 19:24, Jesse Thompson wrote: >>>>> On 11/25/20 11:30 AM, Alessandro Vesely wrote: >>>>>> Without resorting to ARC, it is still possible to validate author >>>>>> domain's signatures directly if the MLM just adds a subject tag >>>>>> and a footer>>>>> >>>>> I agree that ARC isn't really needed to do this (trust the last hop >>>>> from the MLM and determine the original authenticity from the MLM's >>>>> perspective)>>>> >>>> I didn't mean to trust the MLM. I meant remove the subject tag and >>>> the footer, then the original DKIM signature verifies. See: >>>> https://datatracker.ietf.org/doc/draft-vesely-dmarc-mlm-transform/ >>> >>> When I was at Cisco, with l= and some subject line heuristics I could get >>> probably like 90+% verification rate across the entire company, a company that >>> uses external mailing lists a lot. Definitely not 100% though. >> >> >> DKIM itself is not 100%. You always have lines beginning with "From " or >> occasional autoconversions. >> >> l= doesn't cover multipart/alternative nor Content-Transfer-Encoding: >> base64. In addition, the DKIM spec discourages its usage and suggests >> that "Assessors might wish to ignore signatures that use the tag.">> > > Right, some of the other dkim-light or diff concepts we discussed would be > better than using l= > > We again got hung up on the 100% solution, though... something that handled > subject-prefix and footer in a transport agnostic way might have worked. I'm not clear about the meaning of "100%". If an author domain puts no DKIM signatures, there is no way to verify them. Hence, some compliance of the author domain has to be required. The same holds for conditional signatures. The same holds for MLM transformations. > The fact that DKIM isn't transport agnostic is an achilles heel to even > that, though, since we'd have to come up with a new canonicalization and get > it to widespread adoption before the simple diff could work. As DKIM works in the vast majority of cases (yes, not 100%, but nearly), the idea to discombobulate it for the sake of a meagre set of old-fashioned individuals who still dislike mass social media is a showstopper. Yet, since DMARC standardization itself avails of mailing lists, we may want to get some coherence. > Or require mailing lists to be a lot more strict in how they do their email > rewriting, but I imagine that's harder work than even ARC. They are quite strict already. For example, I received the message I'm replying to in both my top and dmarc folders. Both copies of the message have the correct From:. The MLM copy was authenticated like so: Authentication-Results: wmail.tana.it; spf=pass smtp.mailfrom=ietf.org; dkim=pass reason="Original-From: transformed" (whitelisted) header.d=google.com; dkim=pass (whitelisted) header.d=ietf.org header.b=zA0RRbSR; dkim=fail (signature verification failed, whitelisted) header.d=ietf.org header.b=F65GxYqF From: restoring is documented here: https://www.tana.it/sw/zdkimfilter/zdkimfilter.html#mlmtrans Best Ale -- From nobody Tue Dec 1 10:07: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 271083A1423 for ; Tue, 1 Dec 2020 10:07:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.65 X-Spam-Level: X-Spam-Status: No, score=-1.65 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, 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=mtcc-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iPdbCM4dUigL for ; Tue, 1 Dec 2020 10:07:31 -0800 (PST) Received: from mail-pj1-x1029.google.com (mail-pj1-x1029.google.com [IPv6:2607:f8b0:4864:20::1029]) (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 1403D3A1420 for ; Tue, 1 Dec 2020 10:07:30 -0800 (PST) Received: by mail-pj1-x1029.google.com with SMTP id r20so1707830pjp.1 for ; Tue, 01 Dec 2020 10:07:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mtcc-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=QmKQN1M3UQJWU4PcSnftSIcqpwpLoaBdyhFDrBASu9Q=; b=RUG3peS9rn59+OXolhXKkbPSWNvXTvJXLusBRD6ZrHnaWAiufiHAxKg+NzihooLx/a Oj8TPXrn5pgnDGD4cPZEEgHxL0UQzac3uJAzvTDs/XbJNW63b7VWVR1NoMERuEf20BfQ PtcyG1tvk9yxAs5xfA56BAoz4aCJ8g7DHbPu8qMfuCzsH4Au3U+xn/MYmlIB3TjjbyyU Ud48RocpUILddLWwOMOdKTsZ07fI4mqSq4cW+0wZbQkHWSmS8E8KHtmy47F79Jlzu6EZ iEmwU4KhVO/MxC5OdwYFjP0NEws6pnAV4MAyUt7uUuNwRd6k4mW89Np+HUJgXozCMBfw Je+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:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=QmKQN1M3UQJWU4PcSnftSIcqpwpLoaBdyhFDrBASu9Q=; b=WJ1bxTxAMNeI+jfAlsBL5AB414gVqAqn8LaDLJb+0+2hU0CmN7YcO4n5+ioQEYFcB1 oaALJ8fX9tJqDAShPNV04tUYogf1sc94sXYWv7OdMg1yY4D3nY9Kt9uS/VQSOfPxujpk +8jhjw3lqwAEnagl+2uuSoie3ZC9FSI3WANBReygCN+OQq8+aqRpVIm9PYAzsEFwlXRq UI6HIPhxUzl+olqn6c0LgyGHyLhU8+xIiEGLswnkvLJY/Qo0eqdwbVAKIjIODiylEQdM NcJUmk9kVN9xRmmH/DgAFkFU5VLmQTcQ2slj/T7GwlXxuY9gmA/wmyJYwEfjThcOY2hT ifnA== X-Gm-Message-State: AOAM530KBe3CCvAG26LplgUBEQ12idya4GRJSz4GRbndf0/qpdk6A/57 uUa7sZ38k0zJA8VnF81J7FxnzUg+B0I2SQ== X-Google-Smtp-Source: ABdhPJwjwdWb3FbRVXZ1p1rHe+1YE8NPrWXEcuNa6PvTgCpiXJ66dSKl/uQznj3A/Ab/1OCehlcRcA== X-Received: by 2002:a17:90a:664c:: with SMTP id f12mr3906309pjm.94.1606846049697; Tue, 01 Dec 2020 10:07:29 -0800 (PST) Received: from mike-mac.lan (107-182-42-33.volcanocom.com. [107.182.42.33]) by smtp.gmail.com with ESMTPSA id y19sm422256pfp.211.2020.12.01.10.07.28 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 01 Dec 2020 10:07:29 -0800 (PST) To: dmarc@ietf.org References: <8c83fffc-077d-9ddb-db2f-b9763361c60f@tana.it> <39eafc5e-3d9c-0bea-1173-7277070195ea@wisc.edu> <081c42a3-492b-89b7-ad76-ccec48dea091@tana.it> <2d1dca4f-e46a-646c-9fa3-d9ca56c72196@tana.it> From: Michael Thomas Message-ID: <8353c6ab-adac-d0c2-a809-1384aac9b39f@mtcc.com> Date: Tue, 1 Dec 2020 10:07:27 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------CF703D79931BD969D5951E0D" Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] A policy for direct mail flows only, was ARC questions X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 01 Dec 2020 18:07:33 -0000 This is a multi-part message in MIME format. --------------CF703D79931BD969D5951E0D Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 11/30/20 8:56 PM, Brandon Long wrote: > > > On Thu, Nov 26, 2020 at 12:59 AM Alessandro Vesely > wrote: > > On 25/11/2020 20:16, Michael Thomas wrote: > > > When I was at Cisco, with l= and some subject line heuristics I > could get > > probably like 90+% verification rate across the entire company, > a company that > > uses external mailing lists a lot. Definitely not 100% though. > > > DKIM itself is not 100%.  You always have lines beginning with > "From " or > occasional autoconversions. > > l= doesn't cover multipart/alternative nor > Content-Transfer-Encoding: base64. > In addition, the DKIM spec discourages its usage and suggests that > "Assessors > might wish to ignore signatures that use the tag." > Nobody said it can fix everything. It's just that those things are in the long tail. And that admonition sounds like it crept in there after rfc4871 when i wasn't paying attention. i find that a ridiculous overreaction and begs the question why. Being able recover 90%+ signatures going through mailing lists made our scheme of spear-phish alerting very close to viable. We never got to the point of having to make that call because there was just too many crufty email servers in the company that didn't use the centralized email path to insure their messages were signed. That had nothing to do with whether our scheme could work or not. > > Right, some of the other dkim-light or diff concepts we discussed > would be better than using l= > > We again got hung up on the 100% solution, though... something that > handled subject-prefix and > footer in a transport agnostic way might have worked. The fact that > DKIM isn't transport agnostic > is an achilles heel to even that, though, since we'd have to come up > with a new canonicalization > and get it to widespread adoption before the simple diff could work.  > Or require mailing lists to > be a lot more strict in how they do their email rewriting, but I > imagine that's harder work than > even ARC. > > Frankly all it would take is a google or another large mail provider to publicly state that unless a mailing list supports BCP XYZ, your mail will be subject to very strict scrutiny and likely not delivered to get the attention of mailing list providers. That was my suggestion back in the day but it was scoffed at because people could point to some edge case that generates .001% of list traffic and thus invalidating the entire approach. The best is definitely the enemy of the good here. People really need to keep in mind that service provider email is not the only game in town. That point keeps getting lost. Mike --------------CF703D79931BD969D5951E0D Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit


On 11/30/20 8:56 PM, Brandon Long wrote:


On Thu, Nov 26, 2020 at 12:59 AM Alessandro Vesely <vesely@tana.it> wrote:
On 25/11/2020 20:16, Michael Thomas wrote:

> When I was at Cisco, with l= and some subject line heuristics I could get
> probably like 90+% verification rate across the entire company, a company that
> uses external mailing lists a lot. Definitely not 100% though.


DKIM itself is not 100%.  You always have lines beginning with "From " or
occasional autoconversions.

l= doesn't cover multipart/alternative nor Content-Transfer-Encoding: base64.
In addition, the DKIM spec discourages its usage and suggests that "Assessors
might wish to ignore signatures that use the tag."

Nobody said it can fix everything. It's just that those things are in the long tail. And that admonition sounds like it crept in there after rfc4871 when i wasn't paying attention. i find that a ridiculous overreaction and begs the question why.

Being able recover 90%+ signatures going through mailing lists made our scheme of spear-phish alerting very close to viable. We never got to the point of having to make that call because there was just too many crufty email servers in the company that didn't use the centralized email path to insure their messages were signed. That had nothing to do with whether our scheme could work or not.



Right, some of the other dkim-light or diff concepts we discussed would be better than using l= 

We again got hung up on the 100% solution, though... something that handled subject-prefix and
footer in a transport agnostic way might have worked.  The fact that DKIM isn't transport agnostic
is an achilles heel to even that, though, since we'd have to come up with a new canonicalization
and get it to widespread adoption before the simple diff could work.  Or require mailing lists to
be a lot more strict in how they do their email rewriting, but I imagine that's harder work than
even ARC.



Frankly all it would take is a google or another large mail provider to publicly state that unless a mailing list supports BCP XYZ, your mail will be subject to very strict scrutiny and likely not delivered to get the attention of mailing list providers. That was my suggestion back in the day but it was scoffed at because people could point to some edge case that generates .001% of list traffic and thus invalidating the entire approach. The best is definitely the enemy of the good here.

People really need to keep in mind that service provider email is not the only game in town. That point keeps getting lost.

Mike

--------------CF703D79931BD969D5951E0D-- From nobody Tue Dec 1 14:17: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 632B83A03F1 for ; Tue, 1 Dec 2020 14:17:20 -0800 (PST) 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 (2048-bit key) header.d=iecc.com header.b=XdFOFpQb; dkim=pass (2048-bit key) header.d=taugh.com header.b=INJmGjuZ Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2zqWiTW9yOEg for ; Tue, 1 Dec 2020 14:17:18 -0800 (PST) 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 9A64E3A03C9 for ; Tue, 1 Dec 2020 14:17:18 -0800 (PST) Received: (qmail 78072 invoked from network); 1 Dec 2020 22:17:15 -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=130f4.5fc6c0eb.k2012; i=johnl-iecc.com@submit.iecc.com; bh=xLnYU9z6saRW44p9YamdsH8NKg6qN3dQq67EoNFxGBY=; b=XdFOFpQbeyxOosdIl+SByPqvTdqngRnlhoiueU0IFWUIZj+GQkQ3dbLnjg/2RhMKPZ++dyxYoT2wWTzisvLUKB8Ux2nWKxHm2sE4NrffVhBlKhDJ2Uc1GiLHYxjGsWymvHk0kF0Xvvv8D5Kr4A7I9ZMT+9T0sZ3hONYAIVgoxf6gikLv09Z4npmi9FHbIvWhRLtaAx0XDNJYiM8A1xqsh5l/Ooju3uctJTLSGkb3D/H3F0aZLILjeIWozt7pMUl/4Ng0mUf5u+FYOrU2T1PrhQEt0sdqF0MjURHZUvofapfofv/mlO+62fSjiRdyza/HCyhbBSoYu0rLFf68LWAzPg== DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:mime-version:content-type; s=130f4.5fc6c0eb.k2012; olt=johnl-iecc.com@submit.iecc.com; bh=xLnYU9z6saRW44p9YamdsH8NKg6qN3dQq67EoNFxGBY=; b=INJmGjuZNZ2OzLcm4VAvL6j3rLW9KSr/UVDLOCpT4ruQpIPp3d7uJO27KW6m80FW91tNfIY3NEVFvYjZKjbCrLTr0o7IZ5bFIazScGYnjENujd4LEe6WXwaOG+UPamY+75eaub0TzPwFUZ5IKGs/OZDj35+idsDkC98jmYiaqEfg8h50UMAmBEhQYmiX1XY55DECqE60axO5BeKQVQnEMeypdFzFEIem2un1jb5JO6MD+JhZxVmJc7y0xHlW2By2LD25e7TM4+7rUKcJZtqVlnMlTV60uPAlylVJbEMG79ySvVeQ32XBRko8d3NuigJD9cpsu26Bq2k9M3t0miQwMA== 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; 01 Dec 2020 22:17:15 -0000 Date: 1 Dec 2020 17:17:15 -0500 Message-ID: From: "John R Levine" To: dmarc@ietf.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="0-1471237373-1606861035=:99975" Archived-At: Subject: [dmarc-ietf] Ticket #1 - SPF alignment X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 01 Dec 2020 22:17:20 -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-1471237373-1606861035=:99975 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT We would like to close this ticket by Dec 15, two weeks from now, so short trenchant comments are welcome. Ticket #1 is about SPF alignment. We need to replace references to 4408 with 7408, ando clarify what if anything we do with SPF HELO checks if the MAIL FROM is null. One possibility is to say only MAIL FROM SPF counts, if you want to align your bounces, sign them. The other is to explicitly say that HELO alignment is OK on bounces. R's, John ================================================================ From: Anne Bennett Date: Fri, 16 Jan 2015 19:10:56 -0500 Subject: [dmarc-ietf] SPF RFC 4408 vs 7208 On Jan 6, Murray S. Kucherawy confirmed fixing the reference for the SPF RFC from the now-obsolete 4408 to 7208 ("Fixed in -11"). However, -12 still has, in section "3.1. Identifier Alignment": For example, [DKIM] authenticates the domain that affixed a signature to the message, while [SPF] authenticates either the domain that appears in the RFC5321.MailFrom? portion of [SMTP] or the RFC5321.EHLO/HELO domain if the RFC5321.MailFrom? is null (in the case of Delivery Status Notifications). Actually, RFC 7208 states that: Checking "HELO" before "MAIL FROM" is the RECOMMENDED sequence if both are checked. ... and implies that if the first check passes, the second is unnecessary: If a conclusive determination about the message can be made based on a check of "HELO", then the use of DNS resources to process the typically more complex "MAIL FROM" can be avoided. So the RFC5321.EHLO/HELO domain is checked not only if the RFC5321.MailFrom? is null - in fact in cases where sites have followed the RFC 7208 recommendation, it will be checked first, at least by a "pure SPF" implementation. This means, first of all, that the -12 text above needs fixing. But also, I'm struggling with what it means for alignment. I can think of some real-life cases where only one of HELO or MAIL FROM aligns with RFC5322.From, even though both would "pass" in a pure SPF check. IMHO, Section "3.1.2. SPF-authenticated Identifiers" needs to be clarified to better take HELO into account. I'd like to see an approach similar to that for DKIM, where it is explicitly stated that: a single email can contain multiple DKIM signatures, and it is considered to be a DMARC "pass" if any DKIM signature is aligned and verifies. Similarly, I think that for SPF, it should be considered a pass if either the MAIL FROM or the HELO is aligned and results in a pass at the SPF level. But whether it is decided to take into account both HELO and MAIL FROM, or whether it is decided to ignore HELO (modulo its use to construct an artificial MAIL FROM if the latter is null), the text should IMHO make this clear one way or another, both in "3.1.2. SPF-authenticated Identifiers": In relaxed mode, the [SPF]-authenticated domain and RFC5322.From domain must have the same Organizational Domain. In strict mode, only an exact DNS domain match is considered to produce identifier alignment. ... and in "4.1. Authentication Mechanisms": o [SPF], which authenticates the domain found in an [SMTP] MAIL command when it is the authorized domain. In both cases, the text should specifically mention HELO, and whether to include or exclude a HELO SPF result, in view of HELO's prominence in RFC 7208. If it is decided to allow both HELO and MAIL FROM results to be passed back to DMARC, then in section "6.6.2. Determine Handling Policy", item 4 should be updated to reflect that as well. --0-1471237373-1606861035=:99975-- From nobody Tue Dec 1 14:21: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 BA33F3A0596 for ; Tue, 1 Dec 2020 14:21:51 -0800 (PST) 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 (2048-bit key) header.d=iecc.com header.b=kcaF2EUT; dkim=pass (2048-bit key) header.d=taugh.com header.b=THpAd0Nb Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2sFkPkSY02VY for ; Tue, 1 Dec 2020 14:21:50 -0800 (PST) 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 DC38B3A0639 for ; Tue, 1 Dec 2020 14:21:49 -0800 (PST) Received: (qmail 79393 invoked from network); 1 Dec 2020 22:21:48 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:mime-version:content-type:content-id; s=1361d.5fc6c1fc.k2012; i=johnl-iecc.com@submit.iecc.com; bh=BXeCkYHRtkPgHxm0Y1slQVGNjbPHQqz3Fi/NmSI197M=; b=kcaF2EUTZOZ1VgqI68M+AsMcHhcXr0cRSq+AzExoQ/6R9/cRe5qcY+B5XUAZ9+ewY0bJx75o8ZkJnsOKeWPkSbRoPsoMrTJ8+/FOyj2OsZIECwVa1BNaeeNeS/wJ0pFUmMQvgQoCdVNBZT6o009+//oV31zmigrDPb6U1u/ZHlV4RYYbeF5BWeLGlQVdE/t8k7JhK3wEwxzHn9mnYDfaEtZcaSjJmXdRDb9MqWE0qZiUYi0lAce+VjV80q8eJ9om/6Jiy1gsarObkY5qQwWRGiM82Zh5YQESsoVdEL28LtaRSAL48BNX/gpvEi0cFdXvx+AWpFwvUbgNR9WvkTDPOA== DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:mime-version:content-type:content-id; s=1361d.5fc6c1fc.k2012; olt=johnl-iecc.com@submit.iecc.com; bh=BXeCkYHRtkPgHxm0Y1slQVGNjbPHQqz3Fi/NmSI197M=; b=THpAd0Nb5ZisKT1O7zGAHOx0f4DyZP96b5dbO88JxWXb7t2zBH0qroluSwLCb2OI+3nJVEK0p2RcOT+0LA/ugbB1M2TeL45hmWQsjQk6tNoaZOgiQxOaTicUpvbdhhxbj7zIUTmoJrWM/ayo33Ad9pLHqJL8sG82RK4Q8yOTTs+I4yKHGs6E5vJgwRntIMibXMgtTj+HET9kHDDRqAKqAtgJqNFWcoH4xR6zYgECk2R3ofb0D8AkFG+sRWfc7nsN7dF6KV10xZwwPULMlIT/u5dU77wak07rpiujikidZGS+c8p33kZNr1VVGEF+Mg580gopcjySQTY5hgm7rAy8ZQ== 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; 01 Dec 2020 22:21:48 -0000 Date: 1 Dec 2020 17:21:48 -0500 Message-ID: From: "John R Levine" To: dmarc@ietf.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="0-1471237373-1606861035=:99975" Content-ID: <39247d61-9dd8-50e1-6316-a9ecc3923af@iecc.com> Archived-At: Subject: [dmarc-ietf] Ticket #42 - Expand DMARC reporting URI functionality X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 01 Dec 2020 22:21:52 -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-1471237373-1606861035=:99975 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT Content-ID: <46231ee-c343-1ff8-6cf3-19b33167f56b@iecc.com> We would like to close this ticket by Dec 15, two weeks from now, so short trenchant comments are welcome. Ticket #1 is about https reporting. Early drafts of the DMARC spec had a poorly defined http report which we took out. I propose we add back https reporting similar to that for mta-sts, with a POST of the gzipped report to the HTTPS URI. R's, John ================================================================ Right now, reporting only functions via mailto: but other functionality had been previously discussed. Does the group wish to extend reporting mechanisms? See: ​https://mailarchive.ietf.org/arch/msg/dmarc/iKpLKGdneTs85ioOiG_RwR5Vssc/ Changed by johnl@… We can adapt the approach MTA-STS uses in RFC 8460. If rua= has an https URI, the reporter uses HTTP POST to that URI with the report as an uncompressed or gzipped XML file as the POST body. The media type is the same as is used in mail reports, application/xml or application/gzip. Reports SHOULD be gzipped. If we keep the !size hack, they MUST be no larger than the size limit. I suppose failure reports could be posted the same way with the same message type as if mailed, but they're not usually very big and I don't think there are many generated. --0-1471237373-1606861035=:99975-- From nobody Tue Dec 1 15:17: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 B35223A0B02 for ; Tue, 1 Dec 2020 15:17:05 -0800 (PST) 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 (2048-bit key) header.d=iecc.com header.b=rbggmujj; dkim=pass (2048-bit key) header.d=taugh.com header.b=O6I3mKGY Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pNj4rLVcMkbt for ; Tue, 1 Dec 2020 15:17:04 -0800 (PST) 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 269CE3A0AFD for ; Tue, 1 Dec 2020 15:17:03 -0800 (PST) Received: (qmail 93672 invoked from network); 1 Dec 2020 23:17:02 -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=16de6.5fc6ceee.k2012; i=johnl-iecc.com@submit.iecc.com; bh=VFHXMSFxzYLXB7V27lgL/ftbkamWWZWO7BQNJMAgl7w=; b=rbggmujjGqTiqAgbChpn3YZn1HhV9nJ03qyiYKK9eWP1auXWLisXXpWapKXFfYdvX5pgcMjhTlFslHOHJYbZ3kH530anc0rC2RVAjUdBGs1VCM8J2zmAIgWQ0DnB9CocfhR+Z3zJOr8RVqz8rZWUFsdh+geW015hWvAIArZJlCjvTrDazkBtpdJMTfVGK5NBJB5vCKuLOyKKBGr5znTlbim2Q3skzh/mP/BhzRtKi7P4oZih4xDyen9hsMhNA3LY4OwmEH1eAI1tU084bm6vh/uNiOHGMaYEe8w2nI3Uj2zcwmE3PmMOMW/LNUuB4qto3/3iwAQOXDw5PdtC18ptvg== DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:mime-version:content-type; s=16de6.5fc6ceee.k2012; olt=johnl-iecc.com@submit.iecc.com; bh=VFHXMSFxzYLXB7V27lgL/ftbkamWWZWO7BQNJMAgl7w=; b=O6I3mKGYHj7uv7JmtEBZZHzdb5hRNIaoDMY6ftBjTzlnhOPLXYe6DzzO6J+BKsQ3w048glbsX7mfvEzidXzlr1fycAzJ+4iUHt1Ds1mhY4GZqZCNBHUw4Al2MB6chIy/hjc4v31Ylk1ifH6Zl/T6ETk1ul3z7uxkOtHxstiVlJEmU/Cd3nVMyACv9ao/Kz1/9Ud+LEuyB/WHfNx0/jSZgl3MFUvMdnEyORU9P1Wu0valcoOKQe0dxH2LQftJga7jZOsymXWzGOqNH617068MrgGDrzkGzzeEDHS1T8HpcUVEWhuW1TE1062uOAX6A5wUYHzu1QFv19cQ5f9CAhBGRQ== 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; 01 Dec 2020 23:17:01 -0000 Date: 1 Dec 2020 18:17:01 -0500 Message-ID: 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] Ticket #39 - remove p=quarantine X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 01 Dec 2020 23:17:06 -0000 We would like to close this ticket by Dec 15, two weeks from now, so short trenchant comments are welcome. #39 proposes that we remove p=quarantine. I propose we leave it in, even if it is not very useful, because trying to remove it would be too confusing. R's, John ================================================================ Is p=quarantine needed? https://mailarchive.ietf.org/arch/msg/dmarc/fR905EgS6tXpsJTHzWCRCeR9L_0/ From nobody Tue Dec 1 15:20: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 A4DE13A0B16 for ; Tue, 1 Dec 2020 15:20:25 -0800 (PST) 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 IJEcwsvfHLfM for ; Tue, 1 Dec 2020 15:20:23 -0800 (PST) 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 979B33A0B15 for ; Tue, 1 Dec 2020 15:20:23 -0800 (PST) Received: by mail-vs1-xe2e.google.com with SMTP id x4so1894789vsp.7 for ; Tue, 01 Dec 2020 15:20:23 -0800 (PST) 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=Ksd80fPGhPtRwHohFvvdSV497er0Ivd0N3qwDXwYH2E=; b=HfbfOIVKIa3TncjXqdLbIGaJ/ilONNIFRRmQpSfLwkIsdez9F77mlzsyHXvhO/uDA4 cm1zs5f8i7EZ82OerhWzxRs6IWUozAQyqnBWitwJe/V5PaTnzeRBuDu6GFdgR7wqqd6W 2Lfa40EGQNflsaVtftabLUlth17k7K5Nq6F0PyNk4GuyhNsK3bH7ctDy8sxFgblsz7in zYd5jZjyyzkZQyychjwqljv3CNugScthlB8Dyi0R4pDRi+TCyzzRb69vIIzWBstzStic BTv2pz/HW7mNDG4sK7iMQEBrs5rTo2ibbhIW8NUakoy/UbiuBwBT0Jelv9nj4spTerXO yOKg== 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=Ksd80fPGhPtRwHohFvvdSV497er0Ivd0N3qwDXwYH2E=; b=FAgbW8Cj9u+VZKmfZqrnaPReshYg9Panx5aXzbgwFS75CgceKGlSrUGDtU81JS8TXS 4JNyLOatqzJZnEtymYsCVbKU/gzR1oa22wfkXEVrb4W9273GjYSY8raettOYgTfwkPV9 r3T2z1C9O8plQoq3RqdneSk8xDgrnF/t/yFuSUHEpg6L1kaKACQW7l4l45d5y3Wqbpuc cP3/WAuRpKUBxlzcNY7XwlJ+bkvUeSBGYjBQkTP5R7JUMezI/aGmNw8M4jDhgikwTUJ0 6QEQB3vs38VeVoZ6Wv5dhigUWvDyy5yBgggwSujxpAJrxy0ZfmBYAgW6tJumA74V+SVN YVjg== X-Gm-Message-State: AOAM53055Z/hqmy/RhL2WPkxpl141o8fDHoA8M4qiuBM+qSVGJcvXk+2 fe8aFzk2+SZgWUPo/jHBRHfcqaQlUW3uqfhoJd4gxo3M X-Google-Smtp-Source: ABdhPJwjGKiHAHFjePs59+4WKPzbtzkui8A5hRaw8ejgETYLyjgit1+yZeNDZJ7Pks2JT6p2w3K2erSRE3FkKaNNdnI= X-Received: by 2002:a67:fad2:: with SMTP id g18mr5261924vsq.45.1606864822592; Tue, 01 Dec 2020 15:20:22 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Douglas Foster Date: Tue, 1 Dec 2020 18:20:12 -0500 Message-ID: To: dmarc@ietf.org Content-Type: multipart/alternative; boundary="000000000000f3e5c905b56f5ec4" Archived-At: Subject: Re: [dmarc-ietf] Ticket #1 - SPF alignment X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 01 Dec 2020 23:20:26 -0000 --000000000000f3e5c905b56f5ec4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 1) ACCEPTABLE: Server Domain matches RFC 5322 From domain, and RFC 5321 Mail From is missing. HELO is an appropriate proxy for the missing Mail From, especially since a missing Mail From implies a system message, such as a server might need to generate. 2) NOT ACCEPTABLE: Server Domain matches RFC 5322 From domain, but RFC 5321 Mail From is a different domain. All this tells us is that the Mail From domain is a client on that system. Being a client of a hosting service does not give the right to speak for the hosting service. Doug Foster On Tue, Dec 1, 2020 at 5:17 PM John R Levine wrote: > We would like to close this ticket by Dec 15, two weeks from now, so shor= t > trenchant comments are welcome. > > Ticket #1 is about SPF alignment. We need to replace references to 4408 > with 7408, ando clarify what if anything we do with SPF HELO checks if > the MAIL FROM is null. One possibility is to say only MAIL FROM SPF > counts, if you want to align your bounces, sign them. The other is to > explicitly say that HELO alignment is OK on bounces. > > R's, > John > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > From: Anne Bennett > Date: Fri, 16 Jan 2015 19:10:56 -0500 > Subject: [dmarc-ietf] SPF RFC 4408 vs 7208 > > On Jan 6, Murray S. Kucherawy confirmed fixing the reference for > the SPF RFC from the now-obsolete 4408 to 7208 ("Fixed in -11"). > However, -12 still has, in section "3.1. Identifier Alignment": > For example, [DKIM] authenticates the domain that affixed a > signature to the message, while [SPF] authenticates either > the domain that appears in the RFC5321.MailFrom? portion of > [SMTP] or the RFC5321.EHLO/HELO domain if the RFC5321.MailFrom? > is null (in the case of Delivery Status Notifications). > Actually, RFC 7208 states that: > Checking "HELO" before "MAIL FROM" is the RECOMMENDED sequence > if both are checked. > > ... and implies that if the first check passes, the second > is unnecessary: > > If a conclusive determination about the message can be made > based on a check of "HELO", then the use of DNS resources to > process the typically more complex "MAIL FROM" can be avoided. > So the RFC5321.EHLO/HELO domain is checked not only if the > RFC5321.MailFrom? is null - in fact in cases where sites have > followed the RFC 7208 recommendation, it will be checked first, > at least by a "pure SPF" implementation. > This means, first of all, that the -12 text above needs fixing. > But also, I'm struggling with what it means for alignment. > I can think of some real-life cases where only one of > HELO or MAIL FROM aligns with RFC5322.From, even though > both would "pass" in a pure SPF check. IMHO, Section > "3.1.2. SPF-authenticated Identifiers" needs to be clarified > to better take HELO into account. > I'd like to see an approach similar to that for DKIM, where it > is explicitly stated that: > a single email can contain multiple DKIM signatures, and it > is considered to be a DMARC "pass" if any DKIM signature is > aligned and verifies. > Similarly, I think that for SPF, it should be considered a pass > if either the MAIL FROM or the HELO is aligned and results in a > pass at the SPF level. > But whether it is decided to take into account both HELO and MAIL > FROM, or whether it is decided to ignore HELO (modulo its use to > construct an artificial MAIL FROM if the latter is null), the text > should IMHO make this clear one way or another, both in "3.1.2. > SPF-authenticated Identifiers": > In relaxed mode, the [SPF]-authenticated domain and > RFC5322.From domain must have the same Organizational Domain. > In strict mode, only an exact DNS domain match is considered > to produce identifier alignment. > > ... and in "4.1. Authentication Mechanisms": > > o [SPF], which authenticates the domain found in an > [SMTP] MAIL command when it is the authorized domain. > In both cases, the text should specifically mention HELO, > and whether to include or exclude a HELO SPF result, in view > of HELO's prominence in RFC 7208. > If it is decided to allow both HELO and MAIL FROM results to be > passed back to DMARC, then in section "6.6.2. Determine Handling > Policy", item 4 should be updated to reflect that as > well._______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > --000000000000f3e5c905b56f5ec4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
1) ACCEPTABLE:=C2=A0 =C2=A0Server Domain matches RFC = 5322 From domain, and RFC 5321 Mail From is missing.
HELO is an a= ppropriate proxy for the missing Mail From, especially since a missing=C2= =A0Mail From implies a system message, such as a server might need to gener= ate.

2) NOT ACCEPTABLE:=C2=A0 =C2=A0Server Domain = matches RFC 5322 From domain, but RFC 5321 Mail From is a different domain.=
All this tells us is that the Mail From domain is a client on th= at system.=C2=A0 =C2=A0Being a client=C2=A0of a hosting service does not gi= ve the right to speak for the hosting service.

Dou= g Foster


On Tue, Dec 1, 2020 at 5:17 PM John R Levine = <johnl@taugh.com> wrote:
We would like to clos= e this ticket by Dec 15, two weeks from now, so short
trenchant comments are welcome.

Ticket #1 is about SPF alignment.=C2=A0 We need to replace references to 44= 08
with 7408, ando clarify what if anything we do with SPF HELO checks if
the MAIL FROM is null.=C2=A0 One possibility is to say only MAIL FROM SPF <= br> counts, if you want to align your bounces, sign them.=C2=A0 The other is to=
explicitly say that HELO alignment is OK on bounces.

R's,
John

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

From: Anne Bennett <anne@=E2=80=A6>
Date: Fri, 16 Jan 2015 19:10:56 -0500
Subject: [dmarc-ietf] SPF RFC 4408 vs 7208

On Jan 6, Murray S. Kucherawy confirmed fixing the reference for
the SPF RFC from the now-obsolete 4408 to 7208 ("Fixed in -11").<= br> However, -12 still has, in section "3.1. Identifier Alignment": For example, [DKIM] authenticates the domain that affixed a
signature to the message, while [SPF] authenticates either
the domain that appears in the RFC5321.MailFrom? portion of
[SMTP] or the RFC5321.EHLO/HELO domain if the RFC5321.MailFrom?
is null (in the case of Delivery Status Notifications).
Actually, RFC 7208 states that:
Checking "HELO" before "MAIL FROM" is the RECOMMENDED s= equence
if both are checked.

... and implies that if the first check passes, the second
is unnecessary:

If a conclusive determination about the message can be made
based on a check of "HELO", then the use of DNS resources to
process the typically more complex "MAIL FROM" can be avoided. So the RFC5321.EHLO/HELO domain is checked not only if the
RFC5321.MailFrom? is null - in fact in cases where sites have
followed the RFC 7208 recommendation, it will be checked first,
at least by a "pure SPF" implementation.
This means, first of all, that the -12 text above needs fixing.
But also, I'm struggling with what it means for alignment.
I can think of some real-life cases where only one of
HELO or MAIL FROM aligns with RFC5322.From, even though
both would "pass" in a pure SPF check. IMHO, Section
"3.1.2. SPF-authenticated Identifiers" needs to be clarified
to better take HELO into account.
I'd like to see an approach similar to that for DKIM, where it
is explicitly stated that:
a single email can contain multiple DKIM signatures, and it
is considered to be a DMARC "pass" if any DKIM signature is
aligned and verifies.
Similarly, I think that for SPF, it should be considered a pass
if either the MAIL FROM or the HELO is aligned and results in a
pass at the SPF level.
But whether it is decided to take into account both HELO and MAIL
FROM, or whether it is decided to ignore HELO (modulo its use to
construct an artificial MAIL FROM if the latter is null), the text
should IMHO make this clear one way or another, both in "3.1.2.
SPF-authenticated Identifiers":
In relaxed mode, the [SPF]-authenticated domain and
RFC5322.From domain must have the same Organizational Domain.
In strict mode, only an exact DNS domain match is considered
to produce identifier alignment.

... and in "4.1. Authentication Mechanisms":

o [SPF], which authenticates the domain found in an
[SMTP] MAIL command when it is the authorized domain.
In both cases, the text should specifically mention HELO,
and whether to include or exclude a HELO SPF result, in view
of HELO's prominence in RFC 7208.
If it is decided to allow both HELO and MAIL FROM results to be
passed back to DMARC, then in section "6.6.2. Determine Handling
Policy", item 4 should be updated to reflect that as well.____________= ___________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
--000000000000f3e5c905b56f5ec4-- From nobody Tue Dec 1 15:55: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 2DF4F3A0B50 for ; Tue, 1 Dec 2020 15:55:55 -0800 (PST) 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 vONoxJ5KVCpc for ; Tue, 1 Dec 2020 15:55:54 -0800 (PST) Received: from mail-pl1-x62b.google.com (mail-pl1-x62b.google.com [IPv6:2607:f8b0:4864:20::62b]) (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 02A3F3A0B4E for ; Tue, 1 Dec 2020 15:55:53 -0800 (PST) Received: by mail-pl1-x62b.google.com with SMTP id x4so49778pln.8 for ; Tue, 01 Dec 2020 15:55:53 -0800 (PST) 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=q82NkWIk9u+4kQ0BX9nTxqfwKnQXQnNR+Uym9fiyuBE=; b=kogMzJBeQtVYiO8/l5Zm/3zxt2TLfIdUD5rif2bXrP5iLmyKrkUUK0btpOVjzWIj9u l+sFBmVxFwidXTF4FAyEpSAtQopW6gli2wV/lYtZMxXdtdPb3UuVWaGO1IXiSGwEy7yQ j2c2GhfNL7TNESNuBNxbtZxWXqn4swtVAxjYgL/1en3gw2kr+ARiZTcy4TJAxRkPBvyg 8ZPdXwC1gRFNY6Ram3o4NnhCno8mXyobBPGJn3ziURJWT/aFX2AsEIh1UedZsMCFQq1I j7TmGf99WE0yFzuoG8XCd8nGfhm76KMgbWolWCIJ5lgKWzhAoe7/CkD+B/zTCZzI0eyb phDA== 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=q82NkWIk9u+4kQ0BX9nTxqfwKnQXQnNR+Uym9fiyuBE=; b=ITZK8+pfeCdHsZXcKNuOJJZ85B5i3PETtJWT2tfcGtRCSwxoBB5GboaDCMwZ+Q02Md etzm46oKBx/lobwJi9czcQJwYEL7WU3bhhP2wcpCdMuEJoQDl1YkVXiIfhhX+fsjIclS W9wyplGDWn5JUioskBUn87TWfBIy4PpSbcUfWUXd8NX9klyeJaDnEoXdI/J0opB1I3Zz nhJNnwHUj0PjgeibcAqYiEoWZHrYoFdV9XDCWdx8aaZp8x7LScmiD33az4NvYdn6gk+m g+ickxWyfK4iyJ9VpSkCtRdvOlwpAD0jI0GAv/KZkXgGdtQo4nZ1uAJ1j9XY0/7soFu2 Oxvw== X-Gm-Message-State: AOAM531dReJKO4tvimeQeBF2BoyBMMtvC8/HTN81Bshv5XJ+ZLkWZlgi ONOe+tOH1zSnZ2yxJCu2ffMF+5smZVw= X-Google-Smtp-Source: ABdhPJyRBHLEMXfSdFBb69IoXjKD4TjOMPHICCmFIwvEAKvutlldVUG7GkJqXqjQXY7KsZ62atGt6Q== X-Received: by 2002:a17:902:6506:b029:da:b472:7131 with SMTP id b6-20020a1709026506b02900dab4727131mr112205plk.38.1606866953195; Tue, 01 Dec 2020 15:55:53 -0800 (PST) Received: from [192.168.0.109] (c-24-130-62-181.hsd1.ca.comcast.net. [24.130.62.181]) by smtp.gmail.com with ESMTPSA id 199sm33769pfb.219.2020.12.01.15.55.52 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 01 Dec 2020 15:55:52 -0800 (PST) To: John R Levine , dmarc@ietf.org References: From: Dave Crocker Message-ID: <2fc01257-3307-c453-18a0-bc423dccfe6a@gmail.com> Date: Tue, 1 Dec 2020 15:55:51 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.5.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] Ticket #39 - remove p=quarantine X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 01 Dec 2020 23:55:55 -0000 On 12/1/2020 3:17 PM, John R Levine wrote: > #39 proposes that we remove p=quarantine.  I propose we leave it in, > even if it > is not very useful, because trying to remove it would be too confusing. If it is confusing to remove it, it is probably confusing to keep it, albeit a different confusion. Since protocol specifications need to be precise in their semantics, so they are understood the same way by both producers and consumers, I suspect the issue, here, is a failure to adequately specify the meaning or a failure to specify something that is mutually useful and desired. So rather that be administratively expeditious for the working group process, I suggest this issue gets some meaningful discussion.  My email archive indicates it hasn't gotten any discussion at all. Just waving this through because it will be a hassle to deal with it invites random differences in its use, and that is death to interoperability. d/ -- Dave Crocker dcrocker@gmail.com 408.329.0791 Volunteer, Silicon Valley Chapter American Red Cross dave.crocker2@redcross.org From nobody Tue Dec 1 16:16: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 BCFD53A0BE7 for ; Tue, 1 Dec 2020 16:16:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.097 X-Spam-Level: X-Spam-Status: No, score=-1.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, FREEMAIL_REPLY=1, HTML_MESSAGE=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 fKNkDk97V9pX for ; Tue, 1 Dec 2020 16:16:21 -0800 (PST) Received: from mail-vs1-xe2a.google.com (mail-vs1-xe2a.google.com [IPv6:2607:f8b0:4864:20::e2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9CCDA3A0BE3 for ; Tue, 1 Dec 2020 16:16:21 -0800 (PST) Received: by mail-vs1-xe2a.google.com with SMTP id q10so720985vsr.13 for ; Tue, 01 Dec 2020 16:16:21 -0800 (PST) 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=GKsZkpWBk5vNM+kpw1lTeH9oQtOEjyACYd5MMjatgM4=; b=fHHrrMUw8pIUrVAZXzEuXp91R+xWx70jWH46tOCA4IHlD88MSrgzpIV3dnWpTqQ0S2 ESFMV21ALPs5+/6gLVuw+dc61bnhhbGX13SZ0PFtNmpk2AfoO6X+Cs5fl8TpnAtn481k QaKqz4HTdurUkxt6RlzB+29suxaVFn6oC66myFIvH9jeIeAjNSIzy48E+71L48Xx3z3p KaFWDwR4k/2qZy8fc7vhiqTBqctg8EN75blC75564czLWlZ+4+YG0ZlNzCsShbHrEmPP ymI7VSdKobg/LPhLXm7xD4bnm68VoLi2DNCSOvqaNqHn/QZD5yLGC3MOQ+IpxAZ6Xyzf yO9g== 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=GKsZkpWBk5vNM+kpw1lTeH9oQtOEjyACYd5MMjatgM4=; b=sygJ4wwmXt8Lpf66/B5ZJmUzna7siuxQfebKYkYIrYHuAC2CJ8eWDofmstkbBE6YPG 2YNEs63YGdcfwWqk4miO9ydD8l4fE/zKdW23hoz0UcmhgeV3Zdiwp0GNUrq+pPRAxU6r foMgNdxdHNZUdCy6H5W3bsvH5Zdc34kHcTA5d20Bjo4BmYKL64hM3w5PAKnSwTsqoacE 8Ed2QLE7jRsWKv4Hfv5x/LCVpnxkbUBxKbAUVyCe6BC0qtl00ZeUtyPf2rZcIV9IMG+2 cj9EC9Dn98sVkYSHGqzUCaQadCqxNThyJufxAxqrKwKp+po80g1ND9bmxT4q8kL8zljd /7Cg== X-Gm-Message-State: AOAM531WyPxbuNAmuxCiv6JqjovzxpF/HpGKvAuaL3RF6PRcOSC/ctzP AAbe8z2J/Hv+3zFQ477a5HzBA+fblAzef2ZYN3W7u9+g X-Google-Smtp-Source: ABdhPJztjymaTjnrIFykwsLliqPW4Esx5PBTljXdrpLDwY7AdgJOIDGMAjG3c0qYkmG799Z3vP0PDaEHAL18XuXX8U0= X-Received: by 2002:a67:2084:: with SMTP id g126mr5548729vsg.42.1606868180517; Tue, 01 Dec 2020 16:16:20 -0800 (PST) MIME-Version: 1.0 References: <2fc01257-3307-c453-18a0-bc423dccfe6a@gmail.com> In-Reply-To: <2fc01257-3307-c453-18a0-bc423dccfe6a@gmail.com> From: Douglas Foster Date: Tue, 1 Dec 2020 19:16:09 -0500 Message-ID: To: dmarc@ietf.org Content-Type: multipart/alternative; boundary="00000000000019c5ea05b570272b" Archived-At: Subject: Re: [dmarc-ietf] Ticket #39 - remove p=quarantine X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 02 Dec 2020 00:16:26 -0000 --00000000000019c5ea05b570272b Content-Type: text/plain; charset="UTF-8" I have always assumed that p=quarantine and pct<>100 were included to provide political cover for "Nervous Nellies" who were afraid to enable p=reject. As an example, suppose Nellie makes the decision enable p=quarantine and then goes badly: If the recipient reports reject instead of quarantine, she can say: "They were not supposed to review it! They did not follow instructions!" If the recipient reports quarantine as requested, she can say: "They agreed to look at it. We can assume that they will release it to the user after seeing that the message is innocuous, but the quarantine disposition decision is not shown in the DMARC reports." -- As an email gateway administrator, what I reject and what I quarantine will be determined by my confidence level in my system's risk assessment. Sender request will have nothing to do with it. Pct<>100 is pretty much similar. A sender can specify pct=20, but that does not mean that I am going to allow spam into my system 80% of the time simply to make the sender happy. Nonetheless, p=quarantine and pct=20 might allow some organizations to move away from p=none, thinking that they are taking "baby steps", and that is a good thing. Disabling a deployed feature is a big deal. Leaving it deployed is a useful ruse to promote deployment. I favor leaving both mechanisms in place. Doug Foster On Tue, Dec 1, 2020 at 6:56 PM Dave Crocker wrote: > On 12/1/2020 3:17 PM, John R Levine wrote: > > #39 proposes that we remove p=quarantine. I propose we leave it in, > > even if it > > is not very useful, because trying to remove it would be too confusing. > > > If it is confusing to remove it, it is probably confusing to keep it, > albeit a different confusion. > > Since protocol specifications need to be precise in their semantics, so > they are understood the same way by both producers and consumers, I > suspect the issue, here, is a failure to adequately specify the meaning > or a failure to specify something that is mutually useful and desired. > > So rather that be administratively expeditious for the working group > process, I suggest this issue gets some meaningful discussion. My email > archive indicates it hasn't gotten any discussion at all. > > Just waving this through because it will be a hassle to deal with it > invites random differences in its use, and that is death to > interoperability. > > > d/ > > -- > Dave Crocker > dcrocker@gmail.com > 408.329.0791 > > Volunteer, Silicon Valley Chapter > American Red Cross > dave.crocker2@redcross.org > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > --00000000000019c5ea05b570272b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I have always assumed that p=3Dquarantine and pct<>1= 00 were included to provide political cover for "Nervous Nellies"= who were afraid to enable p=3Dreject.

As an example, su= ppose Nellie makes the decision enable p=3Dquarantine and then goes badly:<= /div>

If the recipient reports reject instead of quarant= ine, she can say:=C2=A0 =C2=A0"They were not supposed to review it!=C2= =A0 They=C2=A0did not follow instructions!"

I= f the recipient reports quarantine as requested, she can say:=C2=A0 =C2=A0&= quot;They agreed to look at it.=C2=A0 =C2=A0We can assume that they will re= lease it to the user after seeing that the message is innocuous, but the qu= arantine disposition decision is not shown in the DMARC reports."

--

As an email gateway admini= strator, what I reject and what I quarantine will be determined by my confi= dence level in my system's risk assessment.=C2=A0 =C2=A0Sender request = will have nothing to do with it.

Pct<>100 is= pretty much similar.=C2=A0 =C2=A0A sender can specify pct=3D20, but that d= oes not mean that I am going to allow spam into my system 80% of the time s= imply to make the sender happy.=C2=A0 =C2=A0Nonetheless, p=3Dquarantine and= pct=3D20 might allow some organizations to move away from p=3Dnone, thinki= ng that they are taking "baby steps", and that is a good thing.

Disabling a deployed feature is a big deal.=C2=A0 = =C2=A0Leaving it deployed is a useful ruse to promote deployment.=C2=A0 =C2= =A0I favor leaving both mechanisms in place.

Doug = Foster




On Tue, Dec 1, 202= 0 at 6:56 PM Dave Crocker <dcrocke= r@gmail.com> wrote:
On 12/1/2020 3:17 PM, John R Levine wrote:
> #39 proposes that we remove p=3Dquarantine.=C2=A0 I propose we leave i= t in,
> even if it
> is not very useful, because trying to remove it would be too confusing= .


If it is confusing to remove it, it is probably confusing to keep it,
albeit a different confusion.

Since protocol specifications need to be precise in their semantics, so they are understood the same way by both producers and consumers, I
suspect the issue, here, is a failure to adequately specify the meaning or a failure to specify something that is mutually useful and desired.

So rather that be administratively expeditious for the working group
process, I suggest this issue gets some meaningful discussion.=C2=A0 My ema= il
archive indicates it hasn't gotten any discussion at all.

Just waving this through because it will be a hassle to deal with it
invites random differences in its use, and that is death to
interoperability.


d/

--
Dave Crocker
dcrocker@gmail.com<= /a>
408.329.0791

Volunteer, Silicon Valley Chapter
American Red Cross
dave.crocke= r2@redcross.org

_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
--00000000000019c5ea05b570272b-- From nobody Tue Dec 1 17: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 511D53A0E07 for ; Tue, 1 Dec 2020 17:42:58 -0800 (PST) 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 op_SIgTVib5N for ; Tue, 1 Dec 2020 17:42:57 -0800 (PST) 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 2E16D3A0B0C for ; Tue, 1 Dec 2020 17:42:57 -0800 (PST) Received: from [10.10.10.124] (135-180-6-94.fiber.dynamic.sonic.net [135.180.6.94]) (authenticated bits=0) by segv.crash.com (8.15.2/8.15.2/cci-colo-1.7) with ESMTPSA id 0B21gjFN066954 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Wed, 2 Dec 2020 01:42:54 GMT (envelope-from smj@crash.com) DKIM-Filter: OpenDKIM Filter v2.10.3 segv.crash.com 0B21gjFN066954 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=crash.com; s=201506-2k; t=1606873374; bh=szU/IcyfQ7Xub26kXQmmtYlriiiydfmuM4XGDHHevCE=; h=Subject:To:References:From:Date:In-Reply-To; b=R+fczdPr9HJWvQWSzeLNQLOVnMjQLy2Y5hX9X6XO0gEHBJqacqm0RWyVIl+G69Y96 iu8GdNtRaD1HMLBHzqGc56L/6hMJ71+ecTkbD1HvMxgOUlLtzcLmSnkhpSTLGtBn15 b4gMbWnKih4PYaKYHZOhwphUwyVoDAoM0eywJsxfq2SykewJoo++mEKm4sVtuEHLXb I9GsQfcbtqmImlP8cOMHAERJ2baEnaVdzeqNfy4YpF+b7w4Ey1LBVBP2SEyPOQHvGK TxyKl5PKiEMPdvVA0sj32Sl1TWKB3K5Rt70oxRLd+TvBnyI/5QXq//tIkICOlP6mii xa/bE+0SPojww== X-Authentication-Warning: segv.crash.com: Host 135-180-6-94.fiber.dynamic.sonic.net [135.180.6.94] claimed to be [10.10.10.124] To: dmarc@ietf.org References: <2fc01257-3307-c453-18a0-bc423dccfe6a@gmail.com> From: Steven M Jones Message-ID: Date: Tue, 1 Dec 2020 17:42:45 -0800 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]); Wed, 02 Dec 2020 01:42:54 +0000 (UTC) Archived-At: Subject: Re: [dmarc-ietf] Ticket #39 - remove p=quarantine X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 02 Dec 2020 01:42:58 -0000 On 12/1/20 4:16 PM, Douglas Foster wrote: > > I have always assumed that p=quarantine and pct<>100 were included to > provide political cover for "Nervous Nellies" who were afraid to > enable p=reject. p=none, p=quarantine, and the pct= option were all included so that organizations could set policies according to their own risk/reward evaluation, including changes to those evaluations over time. > Pct<>100 is pretty much similar.   A sender can specify pct=20, but > that does not mean that I am going to allow spam into my system 80% of > the time simply to make the sender happy. I really hope no casual readers get the impression that DMARC bypasses spam filtering. DMARC evaluations are expected to be independent of spam evaluations. If there's any overlap here, perhaps it would be for DMARC (and/or underlying protocols) to provide reliable domain attribution to drive a local policy decision about filtering. > Leaving it deployed is a useful ruse to promote deployment.   I favor > leaving both mechanisms in place. While I deplore characterizing these policy elements as a "ruse," I agree that p=quarantine should be kept. --S. From nobody Tue Dec 1 17:43: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 299C93A0E0E for ; Tue, 1 Dec 2020 17:43:16 -0800 (PST) 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, 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 Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=columbia.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 Y1Xt_hqAt1b2 for ; Tue, 1 Dec 2020 17:43:15 -0800 (PST) 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 0F34B3A0EA8 for ; Tue, 1 Dec 2020 17:43:12 -0800 (PST) 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 0B21gnlE026211 for ; Tue, 1 Dec 2020 20:43:12 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=columbia.edu; h=mime-version : from : date : message-id : subject : to : content-type; s=pps01; bh=b1hyf60wMe6iDGaavnK7dI/Ab05t1pLzBNHXdchzmBE=; b=jrZ5uktMcIZ+Ye+GYG3h+r/Wst6OsaWPos+PQMfjFzCE/LVVun1LR0afBKP3XwURvhwO aYPHgrqE1SxFBZGSNLKVZvcnO4Md3dC1z4/0oLKJfg1bX8QLVCVy/jRNt06zrie1Saw3 aU7E86ecT9VBoAmXzNOX5OEsIND58lzu9PkhH/uJX95YCbUW3d9dTugTukvw4YOsHmAn XaEETUi+pr56SJwNbUx4MLXEm+RD80zyZY4WCvECARpO6C2GSAHCyh6/dYaq3m5zg9/C 7pYv+VqwuXazvBJbHalXxY1UHcNcLXxlk381OWGcNkDV+xSePTITCdlF3kIT6GygKzD6 Fg== Received: from sendprodmail12.cc.columbia.edu (sendprodmail12.cc.columbia.edu [128.59.72.20]) by mx0a-00364e01.pphosted.com with ESMTP id 353km0ev4m-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Tue, 01 Dec 2020 20:43:12 -0500 Received: from mail-il1-f197.google.com (mail-il1-f197.google.com [209.85.166.197]) by sendprodmail12.cc.columbia.edu (8.14.4/8.14.4) with ESMTP id 0B21hABw012225 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT) for ; Tue, 1 Dec 2020 20:43:11 -0500 Received: by mail-il1-f197.google.com with SMTP id l2so175303ilj.2 for ; Tue, 01 Dec 2020 17:43:10 -0800 (PST) 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=b1hyf60wMe6iDGaavnK7dI/Ab05t1pLzBNHXdchzmBE=; b=q7KcoEOzQKQJ6Sch5jLVef8Y30oHUtCU4Wfkw/+vNhyBa62jmjPU220CfWKr2SCd2b q7KK98X9K267VdRyn7SWDXH944ZGjqR5WOz470bUF9e4QERZpYGqa6ZObz7AQBHIATMh 0OGFubQ2fiM9DMnli7FtDIKdAe/Viy902qt/0Sfbeir6RVxAsH2gAGPGz0XK9PToyuX6 KJEoFC8G7bLM2UXwS5lIYIfUvsJn94Bw3pevdEdurp4KhfRLgFX20YFvQmBaDB0wP8BF +oQO+rXe0qIL2SM3TBW8x6Yx2uYbpQE03S+ml2ZozDJAh8rJylV9x99h6e9aaJmYYy/u YSGQ== X-Gm-Message-State: AOAM532vctTJ2EX12UxKvn69Ncf0uYS751bqI0G1X4v5sCd+u8LiuOl8 Hfy6/ajDhXAqETsyEMUvFsvy2irlsYsAway/ZPM+vuG60mg9SHbHK6vmLUgxeZljOpvWZzhX3f5 jStglYuyTZ17xKZs5LvysdwgcY8LmoA== X-Received: by 2002:a02:6a59:: with SMTP id m25mr146294jaf.132.1606873389810; Tue, 01 Dec 2020 17:43:09 -0800 (PST) X-Google-Smtp-Source: ABdhPJyQ3uNi7/4kimgPZTdIXI7TXwqny0I79mJoDYhpexhZlXlNLG44prq0Hd0/xxaXM8awf8aHXNaU7JIu2r3LKII= X-Received: by 2002:a02:6a59:: with SMTP id m25mr146281jaf.132.1606873389386; Tue, 01 Dec 2020 17:43:09 -0800 (PST) MIME-Version: 1.0 From: Joseph Brennan Date: Tue, 1 Dec 2020 20:42:58 -0500 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.312, 18.0.737 definitions=2020-12-01_12:2020-11-30, 2020-12-01 signatures=0 X-Proofpoint-Spam-Details: rule=inbound_notspam policy=inbound score=0 priorityscore=1501 bulkscore=10 adultscore=0 malwarescore=0 phishscore=0 mlxlogscore=695 suspectscore=2 spamscore=0 mlxscore=0 impostorscore=10 lowpriorityscore=10 clxscore=1015 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2012020006 Archived-At: Subject: [dmarc-ietf] 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, 02 Dec 2020 01:43:16 -0000 I want to ask again why DMARC should consider any domain other than the one in the Header From. The purpose of DMARC should be stated right at the top of the proposed standard. It is intended to control use of a domain in the Header From. If the Header From has blabla@example.com, the DMARC record for _dmarc.example.com should apply. It does not make sense to me to say that if the Header From is user@alpha.example.com, and there is no _dmarc.alpha.example.com record, then recipient systems should continue to look for _dmarc.example.com and apply the dmarc rule there. I know of no other standard that requires this type of relationship. This is something new. It will require administrators to continually check what their sub- and supra-domains are doing in order to escape interference by DMARC records they did not create. I think this is unreasonable. Only domains interested in applying DMARC should be involved with DMARC. Others should be able to do what they want. I know that otherwise will out rule out DMARC for the "columbia.edu" domain that I administer. -- Joseph Brennan Lead, Email and Systems Applications Columbia University Information Technology From nobody Tue Dec 1 18:06: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 F1FC63A0E8C for ; Tue, 1 Dec 2020 18:06:27 -0800 (PST) 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 zq-etIzByg9K for ; Tue, 1 Dec 2020 18:06:25 -0800 (PST) Received: from mail-ua1-x92b.google.com (mail-ua1-x92b.google.com [IPv6:2607:f8b0:4864:20::92b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61E713A0E8B for ; Tue, 1 Dec 2020 18:06:25 -0800 (PST) Received: by mail-ua1-x92b.google.com with SMTP id r23so28993uak.0 for ; Tue, 01 Dec 2020 18:06:25 -0800 (PST) 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=Y+uQ1X5B6CLT5DCQgBovoJSP2WVmUf6rfYQLQgbcFaY=; b=VCQMPni1HpGlM+9Lx5HrPjQAkuVuvHmVea8JEGqZadtaTn4CPjlt+28oeE2llYxwKx /nZ66s0xwXmaKus79q2eRba9+eMGN3yILhrUbT+CH8SEfNoAckC3TK+u7gpso9bWChrw kQ0CklhAFYsiGI9Cr3zZLOR+yY/eD5mNu/GMFf3Pa3puC0BZ/r+3PMNzeQ8pH4YFAW26 oMWUmp16xqfUoZDNfxjj2ox+gdnbLqEW0WTn3BzcMMlTDtUgDIyDJrBDOJc7kwBNpsY5 pmxkpvm+hHwmimVa9VQMTSUUPn6gt26PwR/dvhCwe5XuLz46qMRMsjwthN8yFmF4wFxV 6rOw== 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=Y+uQ1X5B6CLT5DCQgBovoJSP2WVmUf6rfYQLQgbcFaY=; b=YgEp3dra//zQi+whNlLXq4HKHdESZ5mI0xmqCZjPYtbakAqtKqHs0gfv7FFi0LDgrm r3chi5z3Xj/LlmbCTOxo3c1F8Q9RYbLMX3pchzWxDLZ8SDpYwvwfbfe8CXhnMv9/+PhL kYbP9b070jzGvT4KZFKnZQw8TVB1soTEa6engfWMh+ignJXZtmK6R4FWT6b3R3yV7f5N Av5G0jYZgLvtpSsKj9bKuzItHS55j9gbkSotqIzQnRT8S4Yyf9qNNQvBKhopmMvFv2DD HwelCkYTObMEnXwwspEDQY5ImQ3ygJWD+72kv9u93S4hGNWZkalzHj8Su/Ukst1b6Q4K SIGA== X-Gm-Message-State: AOAM530OzDF046h1KoCMyRX92kbv5G3OUelelFhb4OxELN68nEYYldBa Lubvl5l68Ox7fWyPX2XNRLBMv0ziWhm19+kNVp3ynQ== X-Google-Smtp-Source: ABdhPJxi7Pc9dvcBA4Qp4kOtXuTx8XaZUpsLKneNP+O2pwkSTjpdg2YkmgJ3ift5hqpMEkqldN3jH/9ihbbT2TypqRk= X-Received: by 2002:ab0:6285:: with SMTP id z5mr485839uao.0.1606874784208; Tue, 01 Dec 2020 18:06:24 -0800 (PST) MIME-Version: 1.0 References: <2fc01257-3307-c453-18a0-bc423dccfe6a@gmail.com> In-Reply-To: From: Seth Blank Date: Tue, 1 Dec 2020 18:06:13 -0800 Message-ID: To: Douglas Foster Cc: IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000b62cfd05b571b07c" Archived-At: Subject: Re: [dmarc-ietf] Ticket #39 - remove p=quarantine X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 02 Dec 2020 02:06:28 -0000 --000000000000b62cfd05b571b07c Content-Type: text/plain; charset="UTF-8" Doug, please keep your arguments focused on the technical merits of the matter, and do not make dismissive comments about users and their motivations. Those you refer to as nervous nellies are the domain owners who this protocol is designed for, many of whom are legitimately worried about blocking good mail along with bad, especially in complicated environments. We cannot dismiss a large class of users as being silly just because their operational experience or business needs are different than our own. Seth, as Chair On Tue, Dec 1, 2020 at 4:16 PM Douglas Foster < dougfoster.emailstandards@gmail.com> wrote: > I have always assumed that p=quarantine and pct<>100 were included to > provide political cover for "Nervous Nellies" who were afraid to enable > p=reject. > > As an example, suppose Nellie makes the decision enable p=quarantine and > then goes badly: > > If the recipient reports reject instead of quarantine, she can say: > "They were not supposed to review it! They did not follow instructions!" > > If the recipient reports quarantine as requested, she can say: "They > agreed to look at it. We can assume that they will release it to the user > after seeing that the message is innocuous, but the quarantine disposition > decision is not shown in the DMARC reports." > > -- > > As an email gateway administrator, what I reject and what I quarantine > will be determined by my confidence level in my system's risk assessment. > Sender request will have nothing to do with it. > > Pct<>100 is pretty much similar. A sender can specify pct=20, but that > does not mean that I am going to allow spam into my system 80% of the time > simply to make the sender happy. Nonetheless, p=quarantine and pct=20 > might allow some organizations to move away from p=none, thinking that they > are taking "baby steps", and that is a good thing. > > Disabling a deployed feature is a big deal. Leaving it deployed is a > useful ruse to promote deployment. I favor leaving both mechanisms in > place. > > Doug Foster > > > > > On Tue, Dec 1, 2020 at 6:56 PM Dave Crocker wrote: > >> On 12/1/2020 3:17 PM, John R Levine wrote: >> > #39 proposes that we remove p=quarantine. I propose we leave it in, >> > even if it >> > is not very useful, because trying to remove it would be too confusing. >> >> >> If it is confusing to remove it, it is probably confusing to keep it, >> albeit a different confusion. >> >> Since protocol specifications need to be precise in their semantics, so >> they are understood the same way by both producers and consumers, I >> suspect the issue, here, is a failure to adequately specify the meaning >> or a failure to specify something that is mutually useful and desired. >> >> So rather that be administratively expeditious for the working group >> process, I suggest this issue gets some meaningful discussion. My email >> archive indicates it hasn't gotten any discussion at all. >> >> Just waving this through because it will be a hassle to deal with it >> invites random differences in its use, and that is death to >> interoperability. >> >> >> d/ >> >> -- >> Dave Crocker >> dcrocker@gmail.com >> 408.329.0791 >> >> Volunteer, Silicon Valley Chapter >> American Red Cross >> dave.crocker2@redcross.org >> >> _______________________________________________ >> dmarc mailing list >> dmarc@ietf.org >> https://www.ietf.org/mailman/listinfo/dmarc >> > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > -- *Seth Blank* | VP, Standards and New Technologies *e:* seth@valimail.com *p:* 415.273.8818 This email and all data transmitted with it contains confidential and/or proprietary information intended solely for the use of individual(s) authorized to receive it. If you are not an intended and authorized recipient you are hereby notified of any use, disclosure, copying or distribution of the information included in this transmission is prohibited and may be unlawful. Please immediately notify the sender by replying to this email and then delete it from your system. --000000000000b62cfd05b571b07c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Doug, please keep your arguments focused on the technical = merits of the matter, and do not make dismissive comments about users and t= heir motivations. Those you refer to as nervous nellies are the domain owne= rs who this protocol is designed for, many of whom are legitimately=C2=A0wo= rried about blocking good mail along with bad, especially in complicated en= vironments. We cannot dismiss a large class of users as being silly just be= cause their operational experience or business needs are different than our= own.

Seth, as Chair

On Tue, Dec 1, 2020 at 4:16 PM= Douglas Foster <= dougfoster.emailstandards@gmail.com> wrote:
I have always assumed t= hat p=3Dquarantine and pct<>100 were included to provide political co= ver for "Nervous Nellies" who were afraid to enable p=3Dreject.
As an example, suppose Nellie makes the decision enable p= =3Dquarantine and then goes badly:

If the recipien= t reports reject instead of quarantine, she can say:=C2=A0 =C2=A0"They= were not supposed to review it!=C2=A0 They=C2=A0did not follow instruction= s!"

If the recipient reports quarantine as re= quested, she can say:=C2=A0 =C2=A0"They agreed to look at it.=C2=A0 = =C2=A0We can assume that they will release it to the user after seeing that= the message is innocuous, but the quarantine disposition decision is not s= hown in the DMARC reports."

--

=
As an email gateway administrator, what I reject and what I quar= antine will be determined by my confidence level in my system's risk as= sessment.=C2=A0 =C2=A0Sender request will have nothing to do with it.
=

Pct<>100 is pretty much similar.=C2=A0 =C2=A0A se= nder can specify pct=3D20, but that does not mean that I am going to allow = spam into my system 80% of the time simply to make the sender happy.=C2=A0 = =C2=A0Nonetheless, p=3Dquarantine and pct=3D20 might allow some organizatio= ns to move away from p=3Dnone, thinking that they are taking "baby ste= ps", and that is a good thing.

Disabling a de= ployed feature is a big deal.=C2=A0 =C2=A0Leaving it deployed is a useful r= use to promote deployment.=C2=A0 =C2=A0I favor leaving both mechanisms in p= lace.

Doug Foster




On Tue, Dec 1, 2020 at 6:56 PM Dave Crocker <dcrocker@gmail.com>= wrote:
On 12/1/= 2020 3:17 PM, John R Levine wrote:
> #39 proposes that we remove p=3Dquarantine.=C2=A0 I propose we leave i= t in,
> even if it
> is not very useful, because trying to remove it would be too confusing= .


If it is confusing to remove it, it is probably confusing to keep it,
albeit a different confusion.

Since protocol specifications need to be precise in their semantics, so they are understood the same way by both producers and consumers, I
suspect the issue, here, is a failure to adequately specify the meaning or a failure to specify something that is mutually useful and desired.

So rather that be administratively expeditious for the working group
process, I suggest this issue gets some meaningful discussion.=C2=A0 My ema= il
archive indicates it hasn't gotten any discussion at all.

Just waving this through because it will be a hassle to deal with it
invites random differences in its use, and that is death to
interoperability.


d/

--
Dave Crocker
dcrocker@gmail.com<= /a>
408.329.0791

Volunteer, Silicon Valley Chapter
American Red Cross
dave.crocke= r2@redcross.org

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


--

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


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

--000000000000b62cfd05b571b07c-- From nobody Tue Dec 1 18:15: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 879673A0F22 for ; Tue, 1 Dec 2020 18:15:04 -0800 (PST) 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 po_nxZ3qu-ib for ; Tue, 1 Dec 2020 18:15:01 -0800 (PST) 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 4497D3A0EA9 for ; Tue, 1 Dec 2020 18:15:01 -0800 (PST) Received: by mail-vs1-xe35.google.com with SMTP id x26so130614vsq.1 for ; Tue, 01 Dec 2020 18:15:01 -0800 (PST) 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=KQomLLiscGwc9NoB5b7VJsq6u7jD/j1GbhPWXXITkFM=; b=VpJfJMlhsxyk22GdGC1k0DcetHRXFPAN4IUs/QVs/S48ZXA0G49f1fMC1kZFC+Pnrt L5Xfd/LnkUK4cN9IOhZiXMmPh4bAddKn/0NPHpDbg0nkiL6BMpkGnOJ4Pe+5DgpTaNHj 8UksaEb609C3ri7ykHfDZGu+p6fVdq/Xub6/65+nu/lKoZM8wOXOlKkzcuuxlbnR4Vns CZBY9d3Ci1/llanBl1j71LfcEj5akPigF7m1nScsjlqVaHRtinhH/BNKnIbYXKXblG1d v9ecZTYM3urmqvWNmCEHeWoloQ1HGg4DPQux6wl+yrCaCbQ6qu2NTDugUX27bLKaxm8k Qxow== 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=KQomLLiscGwc9NoB5b7VJsq6u7jD/j1GbhPWXXITkFM=; b=ODUpezjR2sBVcri2MGPSqAweyIySphzWiqTG9wJimjFicMp8IhMzTv0oMWL2ZA8oBO ub5LAP8ucI5kFXrxRjZB8pWV4ZxMh1xuavgNPcBDkQJs/xxltI9Zpb08RpomY+lCCGf5 m18KGwLXvp490gPm8lWel6CoZd80eMPB/1rz6FIP7o9CD/cjIXUDPl8ex9EU90uz4b+h 3tlJ+U6Gv9dN62rutUlBVYHwh/DOFk94UKyu58ldLsWKSdSU67rqUom5Br6c2FfT4Hkw vIhe8Z0zkj5teot5cJmcRtR3sTpihgyMqHjboecDpLzgZRE/ivqnJaQLivFrZcTgdeU0 mVmA== X-Gm-Message-State: AOAM530T5zjs2JX8KBuILuDQyyTyuWe/AJzxs0py3GaLObEZ/cfd4WOp NVPSvu8kHRfXW8lQJHQzzUPcrt0MTbFQb4NMrrPm X-Google-Smtp-Source: ABdhPJy8sSz3dt0uYBiYyOz/hkfqrOcpY1d5jcsnS0SYonOX4qM+2dJ2c6HvXP9fESGdkEcFVsK00inJBjA+399ytcA= X-Received: by 2002:a67:df8b:: with SMTP id x11mr207892vsk.37.1606875299775; Tue, 01 Dec 2020 18:14:59 -0800 (PST) MIME-Version: 1.0 References: <8c83fffc-077d-9ddb-db2f-b9763361c60f@tana.it> <39eafc5e-3d9c-0bea-1173-7277070195ea@wisc.edu> <081c42a3-492b-89b7-ad76-ccec48dea091@tana.it> <2d1dca4f-e46a-646c-9fa3-d9ca56c72196@tana.it> In-Reply-To: From: Brandon Long Date: Tue, 1 Dec 2020 18:14:46 -0800 Message-ID: To: Alessandro Vesely Cc: IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000717d5e05b571cf81" Archived-At: Subject: Re: [dmarc-ietf] A policy for direct mail flows only, was ARC questions X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 02 Dec 2020 02:15:07 -0000 --000000000000717d5e05b571cf81 Content-Type: text/plain; charset="UTF-8" On Tue, Dec 1, 2020 at 2:37 AM Alessandro Vesely wrote: > On Tue 01/Dec/2020 05:56:46 +0100 Brandon Long wrote: > > On Thu, Nov 26, 2020 at 12:59 AM Alessandro Vesely > wrote: > > > >> On 25/11/2020 20:16, Michael Thomas wrote: > >>> On 11/25/20 11:11 AM, Alessandro Vesely wrote: > >>>> On 25/11/2020 19:24, Jesse Thompson wrote: > >>>>> On 11/25/20 11:30 AM, Alessandro Vesely wrote: > >>>>>> Without resorting to ARC, it is still possible to validate author > >>>>>> domain's signatures directly if the MLM just adds a subject tag > >>>>>> and a footer>>>>> > >>>>> I agree that ARC isn't really needed to do this (trust the last hop > >>>>> from the MLM and determine the original authenticity from the MLM's > >>>>> perspective)>>>> > >>>> I didn't mean to trust the MLM. I meant remove the subject tag and > >>>> the footer, then the original DKIM signature verifies. See: > >>>> https://datatracker.ietf.org/doc/draft-vesely-dmarc-mlm-transform/ > >>> > >>> When I was at Cisco, with l= and some subject line heuristics I could > get > >>> probably like 90+% verification rate across the entire company, a > company that > >>> uses external mailing lists a lot. Definitely not 100% though. > >> > >> > >> DKIM itself is not 100%. You always have lines beginning with "From " > or > >> occasional autoconversions. > >> > >> l= doesn't cover multipart/alternative nor Content-Transfer-Encoding: > >> base64. In addition, the DKIM spec discourages its usage and suggests > >> that "Assessors might wish to ignore signatures that use the tag.">> > > > > Right, some of the other dkim-light or diff concepts we discussed would > be > > better than using l= > > > > We again got hung up on the 100% solution, though... something that > handled > > subject-prefix and footer in a transport agnostic way might have worked. > > I'm not clear about the meaning of "100%". If an author domain puts no > DKIM signatures, there is no way to verify them. Hence, some compliance of > the author domain has to be required. > > The same holds for conditional signatures. > > The same holds for MLM transformations. > Yes, by 100% I meant of messages that were already authenticated and therefore should continue to be authenticated through the relay. Some of the conditional signatures of the "include a diff you can remove to validate the original" attempt seemed to fail on the theory that there were too many things that couldn't be handled. Ie, if your relay removes attachments, including them back in a diff kind of breaks the whole point of that... but how common is that (even less now with Yahoo Groups gone, but possibly still some av/malware relays still do this). I think that one issue we've had is that DMARC is very mechanical and straight-forward, so anything that's fuzzy in response seems more complicated. Anyways, what I'm saying is that I agree, we may have discarded things that might have been much easier/simpler for the 90% case due to wanting something that worked for everything. > > The fact that DKIM isn't transport agnostic is an achilles heel to even > > that, though, since we'd have to come up with a new canonicalization and > get > > it to widespread adoption before the simple diff could work. > > As DKIM works in the vast majority of cases (yes, not 100%, but nearly), > the idea to discombobulate it for the sake of a meagre set of old-fashioned > individuals who still dislike mass social media is a showstopper. Yet, > since DMARC standardization itself avails of mailing lists, we may want to > get some coherence. > There are decided benefits to DKIM being MIME/body unaware, I was merely pointing out that there are things we could do if it was not and part of why some of these alternatives were not pursued. > > Or require mailing lists to be a lot more strict in how they do their > email > > rewriting, but I imagine that's harder work than even ARC. > > They are quite strict already. For example, I received the message I'm > replying to in both my top and dmarc folders. Both copies of the message > have the correct From:. The MLM copy was authenticated like so: > > Authentication-Results: wmail.tana.it; > spf=pass smtp.mailfrom=ietf.org; > dkim=pass reason="Original-From: transformed" (whitelisted) header.d= > google.com; > dkim=pass (whitelisted) header.d=ietf.org > header.b=zA0RRbSR; > dkim=fail (signature verification failed, whitelisted) header.d=ietf.org > header.b=F65GxYqF > > From: restoring is documented here: > https://www.tana.it/sw/zdkimfilter/zdkimfilter.html#mlmtrans That's cool, I thought when I looked at the mailman code (admittedly a long time ago) that it didn't really concern itself with that level of maintaining the format of the message. Unfortunately, the Google Groups code isn't that strict either, though we could have fixed that for a lot of cases (there's always the challenge of inserting a footer that requires changing the charset or cte). Brandon --000000000000717d5e05b571cf81 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Dec 1, 2020 at 2:37 AM Alessa= ndro Vesely <vesely@tana.it> wr= ote:
On Tue 01/D= ec/2020 05:56:46 +0100 Brandon Long wrote:
> On Thu, Nov 26, 2020 at 12:59 AM Alessandro Vesely <vesely@tana.it> wrote:
>
>> On 25/11/2020 20:16, Michael Thomas wrote:
>>> On 11/25/20 11:11 AM, Alessandro Vesely wrote:
>>>> On 25/11/2020 19:24, Jesse Thompson wrote:
>>>>> On 11/25/20 11:30 AM, Alessandro Vesely wrote:
>>>>>> Without resorting to ARC, it is still possible to = validate author
>>>>>> domain's signatures directly if the MLM just a= dds a subject tag
>>>>>> and a footer>>>>>
>>>>> I agree that ARC isn't really needed to do this (t= rust the last hop
>>>>> from the MLM and determine the original authenticity f= rom the MLM's
>>>>> perspective)>>>>
>>>> I didn't mean to trust the MLM.=C2=A0 I meant remove t= he subject tag and
>>>> the footer, then the original DKIM signature verifies.=C2= =A0 See:
>>>> https://datatrack= er.ietf.org/doc/draft-vesely-dmarc-mlm-transform/
>>>
>>> When I was at Cisco, with l=3D and some subject line heuristic= s I could get
>>> probably like 90+% verification rate across the entire company= , a company that
>>> uses external mailing lists a lot. Definitely not 100% though.=
>>
>>
>> DKIM itself is not 100%.=C2=A0 You always have lines beginning wit= h "From " or
>> occasional autoconversions.
>>
>> l=3D doesn't cover multipart/alternative nor Content-Transfer-= Encoding:
>> base64. In addition, the DKIM spec discourages its usage and sugge= sts
>> that "Assessors might wish to ignore signatures that use the = tag.">>
>
> Right, some of the other dkim-light or diff concepts we discussed woul= d be
> better than using l=3D
>
> We again got hung up on the 100% solution, though... something that ha= ndled
> subject-prefix and footer in a transport agnostic way might have worke= d.

I'm not clear about the meaning of "100%".=C2=A0 If an author= domain puts no DKIM signatures, there is no way to verify them.=C2=A0 Henc= e, some compliance of the author domain has to be required.

The same holds for conditional signatures.

The same holds for MLM transformations.

Yes, by 100% I meant of messages that were already authenticated and there= fore should continue to be authenticated through
the relay.
=

Some of the conditional signatures of the "include= a diff you can remove to validate the original" attempt seemed to
fail on the theory that there were too many things that couldn't= be handled.=C2=A0 Ie, if your relay removes attachments,
includi= ng them back in a diff kind of breaks the whole point of that... but how co= mmon is that (even less now with
Yahoo Groups gone, but possibly = still some av/malware relays still do this).

I thi= nk that one issue we've had is that DMARC is very mechanical and straig= ht-forward, so anything that's fuzzy
in response seems more c= omplicated.

Anyways, what I'm saying is that I= agree, we may have discarded things that might have been much easier/simpl= er
for the 90% case due to wanting something that worked for ever= ything.
=C2=A0
> The fact that DKIM isn't transport agnostic is an achilles heel to= even
> that, though, since we'd have to come up with a new canonicalizati= on and get
> it to widespread adoption before the simple diff could work.

As DKIM works in the vast majority of cases (yes, not 100%, but nearly), th= e idea to discombobulate it for the sake of a meagre set of old-fashioned i= ndividuals who still dislike mass social media is a showstopper.=C2=A0 Yet,= since DMARC standardization itself avails of mailing lists, we may want to= get some coherence.

There are decided = benefits to DKIM being MIME/body unaware, I was merely pointing
o= ut that there are things we could do if it was not and part of why some of = these alternatives were not pursued.
=C2=A0
> Or require mailing lists to be a lot more strict in how they do their = email
> rewriting, but I imagine that's harder work than even ARC.

They are quite strict already.=C2=A0 For example, I received the message I&= #39;m replying to in both my top and dmarc folders.=C2=A0 Both copies of th= e message have the correct From:.=C2=A0 The MLM copy was authenticated like= so:

Authentication-Results: wmail.tana.it;
=C2=A0 spf=3Dpass smtp.mailfrom=3Dietf.org;
=C2=A0 dkim=3Dpass reason=3D"Original-From: transformed" (whiteli= sted) header.d=3Dgoogle.com;
=C2=A0 dkim=3Dpass (whitelisted) header.d=3Dietf.org
=C2=A0 =C2=A0 header.b=3DzA0RRbSR;
=C2=A0 dkim=3Dfail (signature verification failed, whitelisted) header.d=3D= ietf.org
=C2=A0 =C2=A0 header.b=3DF65GxYqF

From: restoring is documented here:
https://www.tana.it/sw/zdkimfilter/zdkim= filter.html#mlmtrans

That's cool, I= thought when I looked at the mailman code (admittedly a long time
ago) that it didn't really concern itself with that level of maintain= ing the format
of the message.=C2=A0 Unfortunately, the Google Gr= oups code isn't that strict either,
though we could have fixe= d that for a lot of cases (there's always the challenge
of in= serting a footer that requires changing the charset or cte).

=
Brandon=C2=A0
--000000000000717d5e05b571cf81-- From nobody Tue Dec 1 18:16: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 B21B23A0E8A for ; Tue, 1 Dec 2020 18:16:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.851 X-Spam-Level: X-Spam-Status: No, score=-1.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iecc.com header.b=OHt0z2Tx; dkim=pass (2048-bit key) header.d=taugh.com header.b=HTwvjPVH Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FLs6kYfND2sJ for ; Tue, 1 Dec 2020 18:16:56 -0800 (PST) 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 09BF03A0E1B for ; Tue, 1 Dec 2020 18:16:55 -0800 (PST) Received: (qmail 33267 invoked from network); 2 Dec 2020 02:16:53 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=81e8.5fc6f915.k2012; bh=Feni/JOWAslX7aGS0XbSXZLMibcdVeShU8Hk3xA8pz4=; b=OHt0z2Tx0LWaOJ7TRP1dLjfU8E/Yd9ynJDbmOoGh5RbLvkpstsURDVnpgkBx0fFzXwN5T7fmnxPXtx/4qxJ1BDT0XuzxYcVOSKlZWzKm3AVruMOnPKGengBgPwD1Snq58ELH2KT3fX6My6+MSLgGeg1d09msQPuK1C+gSj2dTRlfq+r1269YHRFk0SV7gB0ivDTw2L6KA51+4EJR7Pq5ip5toLPG4VVhyJPDILgSx+HDOi+ykpAkzda64y3sCr7/d9b5Ym6bK1iCzAoAN4KbnazPqsQikQxH5vcpl+ZScE638SRLiVh8oIiiSenUbiAVB68271Vr+U13JpY/+rC7kA== DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=81e8.5fc6f915.k2012; bh=Feni/JOWAslX7aGS0XbSXZLMibcdVeShU8Hk3xA8pz4=; b=HTwvjPVHp7r+W/JZuzQROudvJHLimZjahQBp8/1hNDf/rNP3xhAIvH1VsHvBAAJT0BGlmGl15EyVVkqbCA3TF0Mc9keCR1ILsPf4TIm53ME091SqEBXvdnfshVht+5z9sZszgQDkOOQ6TO29lv8std0W6TxSqiixhREJEPEH72LIegp/FyL+2LQgQpVytqtuNjYBQbjxPuCUewVJqEPhfmlAeZ8eUQsK3QDKELe8GXIe3VAscwpF0efiRSCmgmKqqFYVw95KrxGZo1yM3G/u9tQyQMMhocaHA5/XgsvE74tc3Ac8cR/7mfJYWf7JAVDTWx7gHZ7yntrupRAcwPiXwg== 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; 02 Dec 2020 02:16:52 -0000 Received: by ary.qy (Postfix, from userid 501) id E8EE128C576A; Tue, 1 Dec 2020 21:16:51 -0500 (EST) Date: 1 Dec 2020 21:16:51 -0500 Message-Id: <20201202021651.E8EE128C576A@ary.qy> From: "John Levine" To: dmarc@ietf.org Cc: smj@crash.com In-Reply-To: Organization: Taughannock Networks X-Headerized: yes Cleverness: minimal Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] Ticket #39 - remove p=quarantine X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 02 Dec 2020 02:16:58 -0000 In article you write: >On 12/1/20 4:16 PM, Douglas Foster wrote: >> >> I have always assumed that p=quarantine and pct<>100 were included to >> provide political cover for "Nervous Nellies" who were afraid to >> enable p=reject. > >p=none, p=quarantine, and the pct= option were all included so that >organizations could set policies according to their own risk/reward >evaluation, including changes to those evaluations over time. Do you think there was a shared understanding of how p=quarantine would be implemented? Put the mail in a spam folder? Put it in some separate place that you can check? (Mimecast does that with some dubious mail) Put it in the inbox with a warning label? I have no idea, my mail system just ignores it so I was wondering what other people do. R's, John From nobody Tue Dec 1 18:22:12 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C52D63A0EAA for ; Tue, 1 Dec 2020 18:22:10 -0800 (PST) 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 z0H1MRwepezZ for ; Tue, 1 Dec 2020 18:22:09 -0800 (PST) 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 D7B5E3A0E8E for ; Tue, 1 Dec 2020 18:22:08 -0800 (PST) Received: by mail-ua1-x92f.google.com with SMTP id a10so24776uan.12 for ; Tue, 01 Dec 2020 18:22:08 -0800 (PST) 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=kv7GK+r8cp58AfxicM7m8kxMoi3D1SdBitrTS8nnhE8=; b=Vb0EhPtiWrEVJNCiGnw8yub6YC0+4Fob+ByvjorYvmOoyOq+sSh2WLT72W5y60e73M FVUlMlrEuc2ssW+eVV6T9qnevBiHpTPvaG1UT1coTuTSCppFm+vwVbxtfIXI4P7wM+E2 tmVyfJcEPw2dKyMzRqX5u3MmpT4ysbvk2tH8v2CX8IKOfFHSWT/dJ2bxvZhoi5j3/+xm RWypwetPuCL50Kr9IgDsDUZjb+Ed73dhB4Y+2vw78kdNdN96qgBCrhevCWczW3ngQ9vp jOcI5/IQiX3y7RSDUVGruD8PHUkVnFtkZ7hTwHkKvDv+hIweDA4UFgH+/u5hqdek1ww1 3pwg== 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=kv7GK+r8cp58AfxicM7m8kxMoi3D1SdBitrTS8nnhE8=; b=pyQH9ryrVUkJgm7r/nfvRF7aczhfnuK+iD4CH4YpTYQWgFWfvhmPTieRyrydV6CnQR eBd9obziWgpaN3fHxegBMRwmsfML6vFI5H2t3U2bM8u+H0I5UHEG8yH6wPuoJ/bfIR9T TRdGt9e7BWXmMfjuTw9yFQkr+pWOHY5mNuqzuy4vTc7TQ286uKRHXvAj5Qudj3Oig0rd cfDnEM7SzjbWpvbvbK2OXEN8eupEwQPVwgcALde5qMZgR6srRexfE1u0yxBA5G6ZUx9D 10TM3unqMl+a1xOSoFD1sUyELtxU2XcAXDuRlbknZufkue794wzmoIdKmDHaV2Lr7XuF DtxA== X-Gm-Message-State: AOAM532ylGWzI2yxnj4pui1eaGQBuHKGSA4T+J2j8+n4UolMQNqplo6X lfSCI1wMntdtH+SJOrKWSIjhKM+dp4vHrP/4XPFM6xaI3w== X-Google-Smtp-Source: ABdhPJwoJ8QrXVySWMBH+J+UG1y/ogJgmknoX9L5dukv/W5KvT2D238HlzHmPMito8bXAfhf9rEhH/tXmHqQOPudQP8= X-Received: by 2002:ab0:2c05:: with SMTP id l5mr507441uar.40.1606875727590; Tue, 01 Dec 2020 18:22:07 -0800 (PST) MIME-Version: 1.0 References: <8c83fffc-077d-9ddb-db2f-b9763361c60f@tana.it> <39eafc5e-3d9c-0bea-1173-7277070195ea@wisc.edu> <081c42a3-492b-89b7-ad76-ccec48dea091@tana.it> <2d1dca4f-e46a-646c-9fa3-d9ca56c72196@tana.it> <8353c6ab-adac-d0c2-a809-1384aac9b39f@mtcc.com> In-Reply-To: <8353c6ab-adac-d0c2-a809-1384aac9b39f@mtcc.com> From: Brandon Long Date: Tue, 1 Dec 2020 18:21:51 -0800 Message-ID: To: Michael Thomas Cc: IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000f1671305b571e863" Archived-At: Subject: Re: [dmarc-ietf] A policy for direct mail flows only, was ARC questions X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 02 Dec 2020 02:22:11 -0000 --000000000000f1671305b571e863 Content-Type: text/plain; charset="UTF-8" On Tue, Dec 1, 2020 at 10:07 AM Michael Thomas wrote: > > On 11/30/20 8:56 PM, Brandon Long wrote: > > Right, some of the other dkim-light or diff concepts we discussed would be > better than using l= > > We again got hung up on the 100% solution, though... something that > handled subject-prefix and > footer in a transport agnostic way might have worked. The fact that DKIM > isn't transport agnostic > is an achilles heel to even that, though, since we'd have to come up with > a new canonicalization > and get it to widespread adoption before the simple diff could work. Or > require mailing lists to > be a lot more strict in how they do their email rewriting, but I imagine > that's harder work than > even ARC. > > Frankly all it would take is a google or another large mail provider to > publicly state that unless a mailing list supports BCP XYZ, your mail will > be subject to very strict scrutiny and likely not delivered to get the > attention of mailing list providers. That was my suggestion back in the day > but it was scoffed at because people could point to some edge case that > generates .001% of list traffic and thus invalidating the entire approach. > The best is definitely the enemy of the good here. > > People really need to keep in mind that service provider email is not the > only game in town. That point keeps getting lost. > arguably we're all here because a large mail provider did make such a change (though to be fair, there were plenty of others who wanted to make that change). While Google might be able to help move things along, there would need to be strong community support for that, no one wants to go this alone and look like the big bully. I also think that you're overestimating what we could do. Ultimately, we serve our customers, and they want their legitimate email, even if it doesn't support BCP XYZ. Brandon --000000000000f1671305b571e863 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Dec 1, 2020 at 10:07 AM Micha= el Thomas <mike@mtcc.com> wrote:=
=20 =20 =20


On 11/30/20 8:56 PM, Brandon Long wrote:
Right, some of the other dkim-light or diff concepts we discussed would be better than using l=3D=C2=A0

We again got hung up on the 100% solution, though... something that handled subject-prefix and
footer in a transport agnostic way might have worked.=C2=A0 The fact that DKIM isn't transport agnostic
is an achilles heel to even that, though, since we'd hav= e to come up with a new canonicalization
and get it to widespread adoption before the simple diff could work.=C2=A0 Or require mailing lists to
be a lot more strict in how they do their email rewriting, but I imagine that's harder work than
even ARC.

Frankly all it would take is a google= or another large mail provider to publicly state that unless a mailing list supports BCP XYZ, your mail will be subject to very strict scrutiny and likely not delivered to get the attention of mailing list providers. That was my suggestion back in the day but it was scoffed at because people could point to some edge case that generates .001% of list traffic and thus invalidating the entire approach. The best is definitely the enemy of the good here.

People really need to keep in mind that service provider email is not the only game in town. That point keeps getting lost.

arguably we're all here because a large mail provider d= id make such a change (though to be fair, there were plenty of others who w= anted to make that change).

While Google might be = able to help move things along, there would need to be strong community sup= port for that, no one wants to go this alone and look like the big bully.

I also think that you're overestimating what we could do.= =C2=A0 Ultimately, we serve our customers, and they want their legitimate e= mail, even if it doesn't support BCP XYZ.=C2=A0

Brandon
--000000000000f1671305b571e863-- From nobody Tue Dec 1 18:50: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 0C9A13A0F5E for ; Tue, 1 Dec 2020 18:50:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.851 X-Spam-Level: X-Spam-Status: No, score=-1.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iecc.com header.b=sZ+n/Ld7; dkim=pass (2048-bit key) header.d=taugh.com header.b=MnBhyAX3 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j8WEDDCfzksn for ; Tue, 1 Dec 2020 18:50:29 -0800 (PST) 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 0750F3A0F4D for ; Tue, 1 Dec 2020 18:50:28 -0800 (PST) Received: (qmail 43669 invoked from network); 2 Dec 2020 02:50: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:cleverness; s=aa91.5fc700f3.k2012; bh=36TjZ7qwbeZKxXMphifSdjcwKl7zLQ1FL+TY+y3X55Q=; b=sZ+n/Ld7pXVXMKlS8mRc+Pg7CuK2G98K2jVshIu3yqafaigDp0b0rpiwgGpQ412CM6d8wWs1CPoPqP7cfjRjh/4nqHO6k1djbkgkk/iBir3q6E0Gd++l/x1sQMpA34mZYhkH5tBC2SK2YktbW8t2/1zoFEd7QT+ozac9TVMh1o613sEW6bcTSLEJIlLDpbXbkc/ZXEntJc0hz8a3q/kA4ojluvBv8AT+fPVbkB8VGFMwksAS2tVAfXGDf14joD6kEIaUETsZoZxQiSrhzuNN7B0gC+3e33QwyKACUOY/E8kzIn2O4tdB5Ij2NuGWPFxVD/8kdDDmN7Ca6eUwS6mPKQ== DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=aa91.5fc700f3.k2012; bh=36TjZ7qwbeZKxXMphifSdjcwKl7zLQ1FL+TY+y3X55Q=; b=MnBhyAX37/oje8Ze80ATBRcAMf9HTpGRVFZVBWBSV0NEvO6BRNPO+OEUhM9pP9E2ea3rBLGznW97mF+DXAIkXz+ZYwi1C0D2S4l0RS6eFLlfIebEUtleO+qFvpqZ1dHGQYnYd84kzxf8RPFEBgoso0FQZ44JrcVKt9whyBaMC7b7BhfDjJ2t3/EXh+OhMS7HN5zFSVchETFDuaYxikUYRrmuPRc8sPAfeBPo41ICIXH099KLALkUFGiEAw9wqIFCIGOmuBhdgJjVq1Fj75thxX8Tsh2l/6Fsb8PMHLZ7xkzrN7m6o/12c/BQ7+sOZWfmvY/+HNolmZFDPHwK480RTg== 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; 02 Dec 2020 02:50:27 -0000 Received: by ary.qy (Postfix, from userid 501) id F16E128C5FDE; Tue, 1 Dec 2020 21:50:26 -0500 (EST) Date: 1 Dec 2020 21:50:26 -0500 Message-Id: <20201202025026.F16E128C5FDE@ary.qy> From: "John Levine" To: dmarc@ietf.org Cc: brennan@columbia.edu In-Reply-To: Organization: Taughannock Networks X-Headerized: yes Cleverness: minimal Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] Domains and tree walk X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 02 Dec 2020 02:50:31 -0000 In article you write: >I know of no other >standard that requires this type of relationship. Here at the IETF, the CAA DNS record that specifies which certificate authority can sign for what domains does a tree walk. If there is a CAA record at example.org it controls signing of foo.example.org and foo.bar.example.org and so forth unless they have their own CAA record. Every applicaton of the public suffix list implicitly does something akin to a tree walk. Its original application was to control cross-site web cookies, to say whether www.foo.co.uk can drop a cookie at foo.co.uk (yes) or co.uk (no). > This is something new. It will require administrators to continually check what their >sub- and supra-domains are doing in order to escape interference by >DMARC records they did not create. I think this is unreasonable. Only >domains interested in applying DMARC should be involved with DMARC. ... Well, it's not that new since we published the DMARC spec five years ago, but this is what I have referred to as the Holy Roman Empire problem. In organizations that are not universities, the entity that is responsible for the registered domain generally sets policies for the whole organization, and a good deal of the DMARC design is there to let them figure out who is sending mail with their name on it from any of their subdomains and identify and adjust senders whose mail doesn't match the policy. We realize that universities are different, organized along the lines of the Holy Roman Empire, and the Elector of Central Asian Cross-Disciplinary Studies feels very strongly about any incursion on their autonomy including their mail setup. On the other hand, I observe that Brown, Cornell, Dartmouth, U Penn, and Yale, whose situations are not altogether unlike Columbia's, all publish DMARC records. Closer to home so do NYU and CUNY. They all say p=none with rua= to collect reports. You might give them a buzz to see how it works for them. R's, John From nobody Tue Dec 1 19:02: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 C9CE43A1084 for ; Tue, 1 Dec 2020 19:02:13 -0800 (PST) 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 B1J-dPAtCzWa for ; Tue, 1 Dec 2020 19:02:11 -0800 (PST) Received: from mail-qt1-x82f.google.com (mail-qt1-x82f.google.com [IPv6:2607:f8b0:4864:20::82f]) (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 892133A107C for ; Tue, 1 Dec 2020 19:02:05 -0800 (PST) Received: by mail-qt1-x82f.google.com with SMTP id v11so86712qtq.12 for ; Tue, 01 Dec 2020 19:02:05 -0800 (PST) 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=kU1KoRnVyi6kPEPphpkeTOsMa7mxaXb8sccZ8Ri2N/Y=; b=d1IzYTwG47pFc5SfiGpxyjShx4pylcK6ZMGRx/n530WOBtZVnMaI056i2C3iOsViaq LMFxaxNOryiaa1NJFAVopcAnkzD1mfzkrZUAslcPhZQHU2VkkyQ6wW4oTPyiOSymFqrH NN1aCupDmbSIL+NijbuflyYzaWuCdQO6As5tnaz6Myx4nVvK0crHFaGQlSdwOz6yZDNn 5R1ydNsb3JrKgkPgsSwhVjQnqMNHOQvce1adYxoVatu5wHCqazZOOErugSD7+RM9prwd EIGNGR8RPWy3ef9Wka15B68jwhZKABRV8U2xQhlQci3rAIsgiBHBsTmM/gGEhXPUEslH Ua+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=kU1KoRnVyi6kPEPphpkeTOsMa7mxaXb8sccZ8Ri2N/Y=; b=eMFM9cpUrfLJOMbm5IipV2C+lUqtKcJxoLtaKkaazKEqqCM2XlnJum330hkUC+wwwS 5R2VUlp5KRT7FUkU15sR78Wb2C2KiQhZqbbs61QR8ERV79doEL49w9y+4UtB5HY8VuwA nN2HfOduNnGEMCQ9h6KhNHVpUTHf4GNFcZ3qQupy51QzvgFj3iXwHZh0jNyPdhYaXvVq EHbh+REBghxFD46m8P4dyI8vTZsKWI7smh0b34Mqw8sUizg2SE2ZdUkuNBbnhPXlWHZk zaW3tqcc+2lp7Tmo9GD2N9jrA5nEBSh0ui4YBJ8ZkR397ws2TzS9N8WELdboqiFjQl+E bRrQ== X-Gm-Message-State: AOAM530mrXzhk9GmRrPOzCvqG1VONDIVsP5mu1EiVGLSgXofdDRhUIoO C4LaUWHA7OsoWHgkc5f5xqHILZ3pJ3nzY703cfnR+/wn X-Google-Smtp-Source: ABdhPJyS071X6JMmAxfllh2Ibt0sbd+nSKk7IbUrh/r+JDROZp49wqEudSJ08RmXifGB4MeZlMhY3DHrStCy+w58XkU= X-Received: by 2002:ac8:5d53:: with SMTP id g19mr654874qtx.354.1606878124502; Tue, 01 Dec 2020 19:02:04 -0800 (PST) MIME-Version: 1.0 References: <2fc01257-3307-c453-18a0-bc423dccfe6a@gmail.com> In-Reply-To: From: Dotzero Date: Tue, 1 Dec 2020 22:01:53 -0500 Message-ID: To: Steven M Jones Cc: IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000cef2a205b572773e" Archived-At: Subject: Re: [dmarc-ietf] Ticket #39 - remove p=quarantine X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 02 Dec 2020 03:02:21 -0000 --000000000000cef2a205b572773e Content-Type: text/plain; charset="UTF-8" On Tue, Dec 1, 2020 at 8:43 PM Steven M Jones wrote: > On 12/1/20 4:16 PM, Douglas Foster wrote: > > > > I have always assumed that p=quarantine and pct<>100 were included to > > provide political cover for "Nervous Nellies" who were afraid to > > enable p=reject. > > p=none, p=quarantine, and the pct= option were all included so that > organizations could set policies according to their own risk/reward > evaluation, including changes to those evaluations over time. > Absolutely agree with Steve on this. The key phrase is "risk/reward evaluation". As about the first person to publish DMARC records (before the specification was public), I went straight to p=reject, but I had the benefit of feedback from participating mailbox providers before we even had an agreed upon reporting format. Even with that, I missed one oddball server for both DKIM signing and SPF. The organization I worked for had a number of heavily abused domains from a direct domain abuse perspective. None of the mail was going through mailing lists or other intermediaries other than a very small fraction of a percent going through vanity domains, etc. My point is that if my circumstances were different I might have gone through p=quarantine or even stayed there permanently. > > > > Pct<>100 is pretty much similar. A sender can specify pct=20, but > > that does not mean that I am going to allow spam into my system 80% of > > the time simply to make the sender happy. > > I really hope no casual readers get the impression that DMARC bypasses > spam filtering. DMARC evaluations are expected to be independent of spam > evaluations. If there's any overlap here, perhaps it would be for DMARC > (and/or underlying protocols) to provide reliable domain attribution to > drive a local policy decision about filtering. > DMARC does one thing and one thing only - It mitigates direct domain abuse. It does not stop spam, phishing or a multitude of other problems. > > > > Leaving it deployed is a useful ruse to promote deployment. I favor > > leaving both mechanisms in place. > > While I deplore characterizing these policy elements as a "ruse," I > agree that p=quarantine should be kept. > Again, I agree with Steve on this. Michael Hammer --000000000000cef2a205b572773e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Dec 1, 2020 at 8:43 PM Steven= M Jones <smj@crash.com> wrote:<= br>
On 12/1/20 4:16 = PM, Douglas Foster wrote:
>
> I have always assumed that p=3Dquarantine and pct<>100 were incl= uded to
> provide political cover for "Nervous Nellies" who were afrai= d to
> enable p=3Dreject.

p=3Dnone, p=3Dquarantine, and the pct=3D option were all included so that <= br> organizations could set policies according to their own risk/reward
evaluation, including changes to those evaluations over time.

Absolutely agree with Steve on this. The key phrase = is "risk/reward evaluation". As about the first person to publish= DMARC records (before the specification was public), I went straight to p= =3Dreject, but I had the benefit of feedback from participating mailbox pro= viders before we even had an agreed upon reporting format. Even with that, = I missed one oddball server for both DKIM signing and SPF. The organization= I worked for had a number of heavily abused domains from a direct domain a= buse perspective.=C2=A0 None of the mail was going through mailing lists or= other intermediaries other than a very small fraction of a percent going t= hrough vanity domains, etc. My point is that if my circumstances were diffe= rent I might have gone through p=3Dquarantine or even stayed there permanen= tly.


> Pct<>100 is pretty much similar.=C2=A0 =C2=A0A sender can specif= y pct=3D20, but
> that does not mean that I am going to allow spam into my system 80% of=
> the time simply to make the sender happy.

I really hope no casual readers get the impression that DMARC bypasses
spam filtering. DMARC evaluations are expected to be independent of spam evaluations. If there's any overlap here, perhaps it would be for DMARC=
(and/or underlying protocols) to provide reliable domain attribution to drive a local policy decision about filtering.

DMARC does one thing and one thing only - It mitigates direct domai= n abuse. It does not stop spam, phishing or a multitude of other problems. =


> Leaving it deployed is a useful ruse to promote deployment.=C2=A0 =C2= =A0I favor
> leaving both mechanisms in place.

While I deplore characterizing these policy elements as a "ruse,"= I
agree that p=3Dquarantine should be kept.

Again, I agree with Steve on this.

Michael Hamm= er
--000000000000cef2a205b572773e-- From nobody Tue Dec 1 19:04: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 C45163A13A5 for ; Tue, 1 Dec 2020 19:04:45 -0800 (PST) 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 Ot-NrFWjC2O3 for ; Tue, 1 Dec 2020 19:04:44 -0800 (PST) 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 12D4F3A1239 for ; Tue, 1 Dec 2020 19:04:02 -0800 (PST) Received: from [10.10.10.124] (135-180-6-94.fiber.dynamic.sonic.net [135.180.6.94]) (authenticated bits=0) by segv.crash.com (8.15.2/8.15.2/cci-colo-1.7) with ESMTPSA id 0B233nnP091232 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Wed, 2 Dec 2020 03:03:58 GMT (envelope-from smj@crash.com) DKIM-Filter: OpenDKIM Filter v2.10.3 segv.crash.com 0B233nnP091232 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=crash.com; s=201506-2k; t=1606878241; bh=WumwRF9ul12Cr7/TZT3rFB42TGUce43Kzu8eW3OIj6M=; h=Subject:To:References:From:Date:In-Reply-To; b=WDTQWc+TNGUbv0gYxtPdWKYSVDb9MA/C7T0f5HoOKmLAmAKZs+S7Y2Va6MzFD2Af3 UPh4N1TYa/UXQyTQYToay4VAectj94KoG8ytCmQr5gWWJRBLH4ZAZ3nwzGxr02g9Ot 1mWtLA4rr6MyPZxSLFM63Ji+kiPRj0BV1ABAXz9tF9HF8kwMyOmAZyCMY6kgZpmFDV ZQlURVC7h8HnPzTh2Codt55piOwEuG3ndsECEYBq6UjooIN9Vd3hkQzYl5g+RfyYED Y66YxjmWmD0KPeAah0ccRD+iR0hZZJXsgu3HKuuYnQauzyTMa6r11OsFE0zb6wi9pS HF9Dr45ueaJ4A== X-Authentication-Warning: segv.crash.com: Host 135-180-6-94.fiber.dynamic.sonic.net [135.180.6.94] claimed to be [10.10.10.124] To: dmarc@ietf.org References: <20201202021651.E8EE128C576A@ary.qy> From: Steven M Jones Message-ID: <327860af-2fa7-63ee-4b89-6e7e383f3d53@crash.com> Date: Tue, 1 Dec 2020 19:03:49 -0800 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: <20201202021651.E8EE128C576A@ary.qy> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.2 (segv.crash.com [72.52.75.15]); Wed, 02 Dec 2020 03:03:58 +0000 (UTC) Archived-At: Subject: Re: [dmarc-ietf] Ticket #39 - remove p=quarantine X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 02 Dec 2020 03:04:52 -0000 On 12/1/20 6:16 PM, John Levine wrote: > In article you write: >> On 12/1/20 4:16 PM, Douglas Foster wrote: >>> I have always assumed that p=quarantine and pct<>100 were included to >>> provide political cover for "Nervous Nellies" who were afraid to >>> enable p=reject. >> p=none, p=quarantine, and the pct= option were all included so that >> organizations could set policies according to their own risk/reward >> evaluation, including changes to those evaluations over time. > Do you think there was a shared understanding of how p=quarantine > would be implemented? Put the mail in a spam folder? Put it in some > separate place that you can check? (Mimecast does that with some > dubious mail) Put it in the inbox with a warning label? Not in the sense of, "All Receivers should do at least X for quarantine." Rather that the Domain Owner is requesting whatever the Receiver implements between rejecting the message and putting it in the inbox, and is willing to apply. Discussions of this nature usually included a recognition - if not a blunt statement - that the Receiver will do whatever they deem best in whatever situation was under consideration. So even if the use case of a small Receiver without a quarantine function wasn't explicitly mentioned on this or that occasion, they would be covered under the, uhm, /force majeure/ clause of Receiver agency. That "clause" came up a _lot_ ... --S. From nobody Tue Dec 1 19:09: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 28AC83A1044 for ; Tue, 1 Dec 2020 19:09:41 -0800 (PST) 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 dgU8FROaLPsT for ; Tue, 1 Dec 2020 19:09:40 -0800 (PST) Received: from mail-pj1-x102e.google.com (mail-pj1-x102e.google.com [IPv6:2607:f8b0:4864:20::102e]) (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 303B43A100E for ; Tue, 1 Dec 2020 19:09:37 -0800 (PST) Received: by mail-pj1-x102e.google.com with SMTP id m5so169385pjv.5 for ; Tue, 01 Dec 2020 19:09:37 -0800 (PST) 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=0jdPvyYInYHX6er7G/csYC02hiP8xYfzeuPXv/bqNlk=; b=Nz052EcQBx6RFK+6+Bmz2WsCUq45rd1NV8kh8N0F2o9xhNIpr1bpKkzGyG90DjqGKn +xS9QoY5TezVGBqM1DKFUkMuauJ4iad/2ddkuGfOFY6xenfpl+4hQE2NneF3pamRRR5p 32GbltOF6/jinY6Y0KLQBh+qZTlMW5vjgTrp3unwXEHEDv5zIPgA5uviJgiIIXXX4jrK 4Q42ZaA7/6YpW0UqG7yVIsNVOLJLnEcSK8mV2DF19KG/rCMaK1JgBZ/WygSylUvud4Yd 8ZHy5mYbvFF4DEfqOl+4M0DcrdTZcjM6u2Qgdpj98tLhXO0YpO+2g5p5EfZpcMJLxNRM 9Mcg== 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=0jdPvyYInYHX6er7G/csYC02hiP8xYfzeuPXv/bqNlk=; b=bN38bE6OipgVJecP7mg7uI1v0pnVscmRBKD3pQ1BXdl0bKdfaCkMY20psDhmYOSdii WH1HW7nwKhJWPoLRUWGzXrXTp2AdLF1rNf6YjD+K4B7wVewWSHZOfXKvc6u0SeMw+qc0 TXvWPzHnfDMlejQHxJ/canlasK0HB2FpWTCs6X23pdRiVw15L4Mk702RobahiABZLEHx w6rpk1r15TlxPtqrWnKSOQ8bMNLnL+uRd8lA5Gz8HPLBoUnNux8Df9JxwUbPTrvgf00x RvJ3CZTcGKrNTmbHZjyER31nKWPLu+w25vURAMKOwA/t86LxGbIDGUhJcj3w+AL54o8S 3SlQ== X-Gm-Message-State: AOAM532wEUXqKBMlFjhpMbrGfJ+6BwKxu+3BF4/8aybclmSvPoC054HD Tf1zCsRXup8Wn5hAK55QchJWUm1Hv30= X-Google-Smtp-Source: ABdhPJzoh02qeCesgZdCRLBJy7O+ujP1NmneBNb4nORAsqxIGFkrh3Bg7o+/tjLTDs6yj4exIk5XsA== X-Received: by 2002:a17:90a:d3d3:: with SMTP id d19mr356330pjw.0.1606878576533; Tue, 01 Dec 2020 19:09:36 -0800 (PST) Received: from [192.168.0.109] (c-24-130-62-181.hsd1.ca.comcast.net. [24.130.62.181]) by smtp.gmail.com with ESMTPSA id w18sm261023pgf.30.2020.12.01.19.09.35 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 01 Dec 2020 19:09:35 -0800 (PST) To: Dotzero , Steven M Jones Cc: IETF DMARC WG References: <2fc01257-3307-c453-18a0-bc423dccfe6a@gmail.com> From: Dave Crocker Message-ID: <065f9a15-d0fb-4564-376b-0c7036079488@gmail.com> Date: Tue, 1 Dec 2020 19:09:35 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.5.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] Ticket #39 - remove p=quarantine X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 02 Dec 2020 03:09:48 -0000 On 12/1/2020 7:01 PM, Dotzero wrote: > DMARC does one thing and one thing only - It mitigates direct domain > abuse. It mitigates direct domain abuse in the rfc5322.From field. It doesn't mitigate domain abuse anywhere else. d/ -- Dave Crocker dcrocker@gmail.com 408.329.0791 Volunteer, Silicon Valley Chapter American Red Cross dave.crocker2@redcross.org From nobody Tue Dec 1 19: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 22BCA3A0799 for ; Tue, 1 Dec 2020 19:41:31 -0800 (PST) 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 at0AdhbvlxK0 for ; Tue, 1 Dec 2020 19:41:29 -0800 (PST) Received: from mail-pf1-x432.google.com (mail-pf1-x432.google.com [IPv6:2607:f8b0:4864:20::432]) (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 2DFAD3A0773 for ; Tue, 1 Dec 2020 19:41:29 -0800 (PST) Received: by mail-pf1-x432.google.com with SMTP id o9so347404pfd.10 for ; Tue, 01 Dec 2020 19:41:29 -0800 (PST) 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=EfKB2KjpUk6/zBYtesGqxmt4Bs1LQCbjDSyMfEMGmf4=; b=PyJuNgBdKGHsNXrhWqONdAnrc4coL07eIlb2nG8ntVSDPMJqcAVZl1dx+v1OUgbfC5 mWlFjF/+3tzaIsR7S77PGC2970ceSt08UuE8bZPFnJYS4vcmTOABJG1MnkebWGWK5PR/ hYNlbQXzm7V25mwueNryxoigSav/Rns5vjJJJznhDHobUe1tQ/Z3Rd+2tO5MjaT5M43c uHZvJH+0NXsJ8GOwCbHQ9UarUeRK7hFOmtXVMOciyWlVwI2yq1VbYcTn3WfZ0zrKJoIw EhwFLws9tSRbt0G831U9BRA9nJax7g3LX+w8M0afQdR2imHbN0iyreC5vAk1mrAjmGWX Pg2w== 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=EfKB2KjpUk6/zBYtesGqxmt4Bs1LQCbjDSyMfEMGmf4=; b=XfFOC/9YuNsh49ago2S3ZCpTn4Ef1q/tu1lIHb1R2Q7NSNtq1cJdamInWLHbPy76nR mQhuPzTU4CGgApvmREQ6+hzj3oDbFWiYamy1dHgE1tSgu+9yGDAq50YoruNgJoW6qWxR GCNyGhDFo6iyXU71Sh7LtxBHhjI7AEQ5BbZ7os3IKJwSQgDOF/LCOMxZEDy7Ip24JvY8 RjOJOSrnlg0hFbDn87DA0UV2DkH5S/DqW6rZHT/LfEe8K78ZXCYB2UjbZXpb6Acx1tou RHnrC8nJ3E6D+85XZxvWh57L6WDOkOjoMvBfQ3h4Zt3i/MBldBQNyHF2ufMnhwhq0jNK LyQQ== X-Gm-Message-State: AOAM531I9J+Ajy1UbehmBb3TGT2geeHSOHlda2c7f3S97ZLhDUxZ+dvi rI3CdtdS0G2nqFIy1loc87E7ndBwR5s= X-Google-Smtp-Source: ABdhPJwllpQngKIZoPibVRNPHwDPdNX3xv1KUbVjF/RE05Mjco0taTtAa+S/rScr3k8rwDOlWnHb2g== X-Received: by 2002:a63:445c:: with SMTP id t28mr786147pgk.373.1606880488359; Tue, 01 Dec 2020 19:41:28 -0800 (PST) Received: from [192.168.0.109] (c-24-130-62-181.hsd1.ca.comcast.net. [24.130.62.181]) by smtp.gmail.com with ESMTPSA id w131sm374254pfd.14.2020.12.01.19.41.27 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 01 Dec 2020 19:41:27 -0800 (PST) To: Steven M Jones , dmarc@ietf.org References: <20201202021651.E8EE128C576A@ary.qy> <327860af-2fa7-63ee-4b89-6e7e383f3d53@crash.com> From: Dave Crocker Message-ID: <2804da89-84d1-f601-9425-0b0d9baf6ae1@gmail.com> Date: Tue, 1 Dec 2020 19:41:26 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 MIME-Version: 1.0 In-Reply-To: <327860af-2fa7-63ee-4b89-6e7e383f3d53@crash.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] Ticket #39 - remove p=quarantine X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 02 Dec 2020 03:41:31 -0000 On 12/1/2020 7:03 PM, Steven M Jones wrote: > Rather that the Domain Owner is requesting whatever the Receiver > implements between rejecting the message and putting it in the inbox, > and is willing to apply. Yes, but... The premise that an author domain owner can, in any way, direct the message disposition decisions of a receiving system is simply false. It's false to a level of silliness, if one adequately considers the complete independence of the receiver from the domain owner. The domain owner can, perhaps, express something about the owner's own concerns for mail that fails dmarc, but that's different from saying anything about the receiver's decisions about how to respond to those expressed concerns. That is, the language expressing the semantics should be changed to be, in a sense, egocentric.  How do I, the domain owner feel about (assess) the meaning of a DMARC failure? I'd frankly recommend changing the labels for these expressions, but expect folk to argue that there is too much installed base and operational history.  After all, we left "Mail From" in place, even after finally realizing it means "Error Return", which is completely different... d/ -- Dave Crocker dcrocker@gmail.com 408.329.0791 Volunteer, Silicon Valley Chapter American Red Cross dave.crocker2@redcross.org From nobody Tue Dec 1 20:15: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 6D1A83A0FDA for ; Tue, 1 Dec 2020 20:15:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.851 X-Spam-Level: X-Spam-Status: No, score=-1.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iecc.com header.b=D7Gn+ELX; dkim=pass (2048-bit key) header.d=taugh.com header.b=l8RMMPVe Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wCv9nnlWY51C for ; Tue, 1 Dec 2020 20:15:26 -0800 (PST) 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 AAEBF3A0FDE for ; Tue, 1 Dec 2020 20:15:26 -0800 (PST) Received: (qmail 65201 invoked from network); 2 Dec 2020 04:15: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:cleverness; s=feae.5fc714dd.k2012; bh=xIbyhN+WnQR+yB9vno4mqAxzem9q+fDbeG1vewEC9dk=; b=D7Gn+ELXe/LS8a8Jd2Bpkg2cIrixMIiFTopMhHglJwr9XPRMji4BEyP8vE7zBvbZk/hZ0fXOeDXz8vnw2c8+XohjJSojBMWTqxRGpc6/rJBfMEvRdjzRM8XFVqho+damdiuAfjg3bOIHrvsHpJThzan+BraPkEmI9x4BwsYlilSRPMg+IP3YV0hyj7f35Ft864qkYx8ktxSTRqn2agFpmGzaylawPVucEqN51uaZHGJKES8qg5UIFgGOW7maUO85T9if1cOh3tRvX4rsX4Wi9hLBNvlGylUEDZmMQ0V67Zhzl2lHZpsZzeZuN5IPNw8k00bpXyl7ZGhuHxdiO3CpAg== DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=feae.5fc714dd.k2012; bh=xIbyhN+WnQR+yB9vno4mqAxzem9q+fDbeG1vewEC9dk=; b=l8RMMPVeDga5ff/wT2Krc/fnjt8fq91ff27PVA+p0sdxfpQCX+fhExGdUQ1nmhyosODylaSqc+MsZcK/rFS3ZeroCDP8pKmt4SvAgHT/aixIo1jAgycdtHMbtaWbdYJNGskwOlbHmCjBYgsidqvpN0s2dUlsz8h0L1MbhC0UoDss8SeHcoQAZMiK7uFIdqLrPRJwLbp6+DONbff5zKlVF/ucB/JG6gE1csNDwqc73Tj8SmUWUQsgkFwcsz6mVgkYvYhOpKha8wbHFRocE2vQ3XBARFBnkxFJwKnUqMySRGACVKy+lbu7FcNYHBZvOqyIaWeXaJbVE8tG1Fw0GkzPSw== 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; 02 Dec 2020 04:15:24 -0000 Received: by ary.qy (Postfix, from userid 501) id 3A67228C81C9; Tue, 1 Dec 2020 23:15:23 -0500 (EST) Date: 1 Dec 2020 23:15:23 -0500 Message-Id: <20201202041524.3A67228C81C9@ary.qy> From: "John Levine" To: dmarc@ietf.org Cc: smj@crash.com In-Reply-To: <327860af-2fa7-63ee-4b89-6e7e383f3d53@crash.com> Organization: Taughannock Networks X-Headerized: yes Cleverness: minimal Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] Ticket #39 - remove p=quarantine X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 02 Dec 2020 04:15:28 -0000 In article <327860af-2fa7-63ee-4b89-6e7e383f3d53@crash.com> you write: >> Do you think there was a shared understanding of how p=quarantine >> would be implemented? ... >quarantine." Rather that the Domain Owner is requesting whatever the >Receiver implements between rejecting the message and putting it in the >inbox, and is willing to apply. I get that but I'm wondering if there is any consistency in what that turns out to be. It is easy to explain what rejecting a message means, and pretty easy to explain do what you would have done if DMARC didn't exist, but that middle region is murky. R's, John From nobody Wed Dec 2 01:48: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 C3C9D3A127A for ; Wed, 2 Dec 2020 01:48:04 -0800 (PST) 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 5RtZ3_zUua62 for ; Wed, 2 Dec 2020 01:47:59 -0800 (PST) Received: from mail.wordtothewise.com (mail.wordtothewise.com [104.225.223.158]) by ietfa.amsl.com (Postfix) with ESMTP id C35273A126D for ; Wed, 2 Dec 2020 01:47:59 -0800 (PST) Received: from [192.168.0.227] (unknown [37.228.231.27]) by mail.wordtothewise.com (Postfix) with ESMTPSA id A0A8C9F149 for ; Wed, 2 Dec 2020 01:47:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=wordtothewise.com; s=aardvark; t=1606902479; bh=Je2mxUTeHmOETMSYEow7txG5ch+RP6bVUSxlWw3qBUA=; h=From:Subject:Date:References:To:In-Reply-To:From; b=fcXZP9a+DnY2oTLZ3hlw2HyyUqNlFt9upCsbvD4hB0vDB4WdJdIlB1whhWoKFtBaj 8H6rh7/JpldMo3SSf+hKrm2/V4zl0Ux/gPDtEb84IgL6VnY8W3eydROGMX0Kb1y0z3 cOSeJR595snSevqgsE/PEt7X2YhKoLRMw6M4IFm4= From: Laura Atkins Content-Type: multipart/alternative; boundary="Apple-Mail=_DDB0727B-A13B-4E86-877C-0D8B6FA89A28" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Date: Wed, 2 Dec 2020 09:47:56 +0000 References: To: IETF DMARC WG In-Reply-To: Message-Id: <5C559553-3F45-494D-9714-F7BC47BB82FF@wordtothewise.com> X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [dmarc-ietf] Ticket #39 - remove p=quarantine X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 02 Dec 2020 09:48:05 -0000 --Apple-Mail=_DDB0727B-A13B-4E86-877C-0D8B6FA89A28 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 1 Dec 2020, at 23:17, John R Levine wrote: >=20 > We would like to close this ticket by Dec 15, two weeks from now, so = short > trenchant comments are welcome. >=20 > #39 proposes that we remove p=3Dquarantine. I propose we leave it in, = even if it > is not very useful, because trying to remove it would be too = confusing. p=3Dquarantine is quite useful, particularly for those folks who are = trying to get to a p=3Dreject state.=20 In practice, senders who publish p=3Dnone don=E2=80=99t find all of the = indirect mail flows as some mailing lists do nothing to transform the = 5322.from address for a p=3Dnone policy. Senders have found that when = they switch from p=3Dnone to p=3Dquarantine pct=3D0 they regularly find = mail that was not failing for a p=3Dnone.=20 p=3Dquarantine should stay in, especially if the goal is to encourage = senders to publish a p=3Dreject. It=E2=80=99s a valuable step in the = deployment process.=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=_DDB0727B-A13B-4E86-877C-0D8B6FA89A28 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On 1 Dec 2020, at 23:17, John R Levine <johnl@taugh.com> = wrote:

We would like to close this ticket by Dec 15, two weeks from = now, so short
trenchant comments are welcome.

#39 proposes that we remove p=3Dquarantine. =  I propose we leave it in, even if it
is not very = useful, because trying to remove it would be too confusing.

p=3Dquarantine is quite useful, = particularly for those folks who are trying to get to a p=3Dreject = state. 

In = practice, senders who publish p=3Dnone don=E2=80=99t find all of the = indirect mail flows as some mailing lists do nothing to transform the = 5322.from address for a p=3Dnone policy. Senders have found that when = they switch from p=3Dnone to p=3Dquarantine pct=3D0 they regularly find = mail that was not failing for a p=3Dnone. 

p=3Dquarantine should stay in, = especially if the goal is to encourage senders to publish a p=3Dreject. = It=E2=80=99s a valuable step in the deployment process. 

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=_DDB0727B-A13B-4E86-877C-0D8B6FA89A28-- From nobody Wed Dec 2 01:56: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 DF62B3A1277 for ; Wed, 2 Dec 2020 01:55:58 -0800 (PST) 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, 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 2gca9OEizdoB for ; Wed, 2 Dec 2020 01:55:57 -0800 (PST) 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 86A763A1274 for ; Wed, 2 Dec 2020 01:55:57 -0800 (PST) Received: from [10.10.10.124] (135-180-6-94.fiber.dynamic.sonic.net [135.180.6.94]) (authenticated bits=0) by segv.crash.com (8.15.2/8.15.2/cci-colo-1.7) with ESMTPSA id 0B29tk0w070503 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 2 Dec 2020 09:55:55 GMT (envelope-from smj@crash.com) DKIM-Filter: OpenDKIM Filter v2.10.3 segv.crash.com 0B29tk0w070503 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=crash.com; s=201506-2k; t=1606902957; bh=00UXW7sNDflRPSUfpz5A2PaEXAuet3zC95W1d0blLFA=; h=Subject:To:References:From:Date:In-Reply-To; b=mnJnLYclF3o5bcMCVzAXhMa8xozUqXfiXjEpATgGVZZ3gcj+/957En91b37UfUyh0 Aq/ReaPYUKT50JQzBd/0ebt9CjHMlHomz4Bxq9I0tYOdCpVYJe5Lyc8QyGTCRhHhlN I6I9eksNt4p6GDIo1IM15O0FH9j+hNA+qAUIenAYQxq338U8MRfBxVbGnlzWtyCTQS Ni0EdQ9/KRlsA4/kOXRvCqXlRlFt5XduDtdUvCa+Ea9mKeDdPNgwnOY7FvP/QCy0aJ fC+vfJEqORtCjz/prg4UHlTjaxnwENjvzVPHGRs7dCf7ZmjGKPVxiqSkoERdJJiARZ bN40go5QGx3EQ== X-Authentication-Warning: segv.crash.com: Host 135-180-6-94.fiber.dynamic.sonic.net [135.180.6.94] claimed to be [10.10.10.124] To: Dave Crocker , dmarc@ietf.org References: <20201202021651.E8EE128C576A@ary.qy> <327860af-2fa7-63ee-4b89-6e7e383f3d53@crash.com> <2804da89-84d1-f601-9425-0b0d9baf6ae1@gmail.com> From: Steven M Jones Message-ID: <1f6cae74-4eed-47f5-7249-e526bf1f5845@crash.com> Date: Wed, 2 Dec 2020 01:55:45 -0800 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: <2804da89-84d1-f601-9425-0b0d9baf6ae1@gmail.com> Content-Type: multipart/alternative; boundary="------------0572F1393EDA5630CA4755B4" 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]); Wed, 02 Dec 2020 09:55:55 +0000 (UTC) Archived-At: Subject: Re: [dmarc-ietf] Ticket #39 - remove p=quarantine X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 02 Dec 2020 09:55:59 -0000 This is a multi-part message in MIME format. --------------0572F1393EDA5630CA4755B4 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 12/1/20 7:41 PM, Dave Crocker wrote: > On 12/1/2020 7:03 PM, Steven M Jones wrote: >> Rather that the Domain Owner is *requesting* whatever the Receiver >> implements between rejecting the message and putting it in the inbox, >> and is willing to apply. > > Yes, but... > > The premise that an author domain owner can, in any way, direct the > message disposition decisions of a receiving system is simply false. > It's false to a level of silliness, if one adequately considers the > complete independence of the receiver from the domain owner. Yes, you are absolutely right. But this is why I wrote "requesting" rather than "commanding (with all the guarantees King Canute had when he commanded the tide to halt)" -- the latter phrasing is just /slightly/ too ponderous even for me... Does "requesting" really imply control over the outcome, rather than the expression of a desire? > I'd frankly recommend changing the labels for these expressions, but > expect folk to argue that there is too much installed base and > operational history. Ah, now maybe we're getting somewhere. But if you toss that notion out, you have to follow up with an example or two. Which labels, and changing them in what way? --S. --------------0572F1393EDA5630CA4755B4 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
On 12/1/20 7:41 PM, Dave Crocker wrote:
On 12/1/2020 7:03 PM, Steven M Jones wrote:
Rather that the Domain Owner is requesting whatever the Receiver implements between rejecting the message and putting it in the inbox, and is willing to apply.

Yes, but...

The premise that an author domain owner can, in any way, direct the message disposition decisions of a receiving system is simply false. It's false to a level of silliness, if one adequately considers the complete independence of the receiver from the domain owner.

Yes, you are absolutely right. But this is why I wrote "requesting" rather than "commanding (with all the guarantees King Canute had when he commanded the tide to halt)" -- the latter phrasing is just /slightly/ too ponderous even for me... Does "requesting" really imply control over the outcome, rather than the expression of a desire?


I'd frankly recommend changing the labels for these expressions, but expect folk to argue that there is too much installed base and operational history.

Ah, now maybe we're getting somewhere. But if you toss that notion out, you have to follow up with an example or two. Which labels, and changing them in what way?

--S.
--------------0572F1393EDA5630CA4755B4-- From nobody Wed Dec 2 02:21: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 8FD873A105C for ; Wed, 2 Dec 2020 02:21:05 -0800 (PST) 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 SlENF3XM1iwI for ; Wed, 2 Dec 2020 02:21:02 -0800 (PST) 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 4EB6C3A0EF0 for ; Wed, 2 Dec 2020 02:21:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1606904457; bh=4KtS+XuOVNz0UbNvfnqNJgV6YOlYPgbuQpnRj+7jrrw=; l=1127; h=To:References:From:Date:In-Reply-To; b=DguB/Ke8Oo10zYcBuIEwXznuf+jZKgzRQimd7eTigP3RYMQemZKXDopo+1Jn0y8VZ +ptWe9dpuevYFEx/PKe+GpZNVCSLvQvrfLUnqa0tmiumIpqBNJOr+YsJ0DpXmhSZYR Ir6zAADrSOhNCtfGFB+OuR9LFnRmOEamzmpAYClTEq9oT3xXTco9XEjwwXItm Authentication-Results: tana.it; auth=pass (details omitted) Original-From: Alessandro Vesely 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.000000005FC76A89.00000C5D; Wed, 02 Dec 2020 11:20:57 +0100 To: dmarc@ietf.org References: From: Alessandro Vesely Message-ID: Date: Wed, 2 Dec 2020 11:20:57 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Ticket #42 - Expand DMARC reporting URI functionality X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 02 Dec 2020 10:21:06 -0000 On Tue 01/Dec/2020 23:21:48 +0100 John R Levine wrote: > We would like to close this ticket by Dec 15, two weeks from now, so short > trenchant comments are welcome. > > [...] > > We can adapt the approach MTA-STS uses in RFC 8460. > > If rua= has an https URI, the reporter uses HTTP POST to that URI with > the report as an uncompressed or gzipped XML file as the POST body. TL;DR: neutral Delivery via https, with possible retry queue, imposes an additional burden to report producers. Since there seem to be less producers than consumers, it may be fair to grant the choice of transport to the former. That is, to make the mailto scheme mandatory and https optional. Even if the the spec allows consumers to specify the transport they like better, there will probably be producers which only honor one type. So, consumers may want to specify both schemes anyway. A better means to control report size is to gauge the reporting interval. The addition of the new transport doesn't seem to simplify things. I fail to see the advantage, but I can cope with it if it comes. Best Ale -- From nobody Wed Dec 2 02:37: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 BE9F13A1361 for ; Wed, 2 Dec 2020 02:37:48 -0800 (PST) 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 SkhkmbggaIxP for ; Wed, 2 Dec 2020 02:37:47 -0800 (PST) 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 CEB383A135F for ; Wed, 2 Dec 2020 02:37:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1606905458; bh=LkVh/cK4eLOeiohsme8T/BFluOamwK0AT4axrC/AtyU=; l=683; h=To:References:From:Date:In-Reply-To; b=C2Vd61MvlPCHOrOi5TCPPihsRMwMeFIZve4qiRc3rxnq/4X6izEhn0TKA9KyZEDoM +QD2KxyAV0rVbzybkyb6tdOKg5SHICkWXOHoPuuaCBqNRKDB0YR0V9LT+rMheTGBg9 Ao7fhoJXfsRkFv22F8dLgmuuBRs/pCWPlh043XKy7hotrkVB9X/0cIZaLD4X+ Authentication-Results: tana.it; auth=pass (details omitted) Original-From: Alessandro Vesely 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.000000005FC76E71.00000E5B; Wed, 02 Dec 2020 11:37:37 +0100 To: dmarc@ietf.org References: From: Alessandro Vesely Message-ID: Date: Wed, 2 Dec 2020 11:37:37 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Ticket #1 - SPF alignment X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 02 Dec 2020 10:37:56 -0000 On Tue 01/Dec/2020 23:17:15 +0100 John R Levine wrote: > We would like to close this ticket by Dec 15, two weeks from now, so short > trenchant comments are welcome. > > [...] > > I think that for SPF, it should be considered a pass if either the MAIL FROM > or the HELO is aligned and results in a pass at the SPF level. +1, especially for bounces. > If it is decided to allow both HELO and MAIL FROM results to be > passed back to DMARC, then in section "6.6.2. Determine Handling > Policy", item 4 should be updated to reflect that as well. If alignment is not known at step 4, both domain names (if different) must be passed to step 5. Best Ale -- From nobody Wed Dec 2 02:40:50 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4EAE3A13BF for ; Wed, 2 Dec 2020 02:40:45 -0800 (PST) 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 eJI34CQD4Mt4 for ; Wed, 2 Dec 2020 02:40:44 -0800 (PST) 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 DFE593A1342 for ; Wed, 2 Dec 2020 02:40:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1606905632; bh=3VFi29qDbLMBuFzx1unz7igrMJmCAcGj84bbo3LjNP0=; l=581; h=To:References:From:Date:In-Reply-To; b=DWlQDyDLsl8MIh5+wqeBm7gz2t0EetAFnXr+X70ATQ5NgyehCBln4qNE4wevsrAMZ QmLTbx0+cN5fVOkZWkyRtSaVJKz/JBi6Ojj0ZyOvh7MmYmlt2uX6gn6UIRVyindaag qOSHEcf9TG2BYbbxuwKFZMlr7YhAj8w44Fxbx/gLKwwwdroowQCFHhHC9Wz3D Authentication-Results: tana.it; auth=pass (details omitted) Original-From: Alessandro Vesely 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.000000005FC76F20.00000F55; Wed, 02 Dec 2020 11:40:32 +0100 To: dmarc@ietf.org References: From: Alessandro Vesely Message-ID: Date: Wed, 2 Dec 2020 11:40:32 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] Ticket #1 - SPF alignment X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 02 Dec 2020 10:40:48 -0000 On Wed 02/Dec/2020 00:20:12 +0100 Douglas Foster wrote: > > 2) NOT ACCEPTABLE:   Server Domain matches RFC 5322 From domain, but RFC 5321 > Mail From is a different domain. > All this tells us is that the Mail From domain is a client on that system. >  Being a client of a hosting service does not give the right to speak for the > hosting service. What if I wanted to collect bounces at a different domain? OTOH, an MSA can relay using a different HELO (or even a different IP), according to the right (categorization) it wants to supply. Best Ale -- From nobody Wed Dec 2 03:11: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 245763A1340 for ; Wed, 2 Dec 2020 03:11:39 -0800 (PST) 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 P5q65vuHprHX for ; Wed, 2 Dec 2020 03:11:36 -0800 (PST) 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 51F013A1354 for ; Wed, 2 Dec 2020 03:11:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1606907491; bh=aFnwLxel99bGaN0ZBtAatEJgstAP6cV5vMwdDTeNrgs=; l=4009; h=To:Cc:References:From:Date:In-Reply-To; b=AnKOV3RCt0QZls6OBGrTOSg+Yyly7mzAesOdd8pgqEKkbwoZCON8T3CrUQtKLk5Ga jFpKiFrXZr2J0kQVH91T/b7XOqVjViiJDluopYti4A4fLkwt4+rnm9OZ9XgE15Auw5 nZaFIZWq+INdMAG25itL4H2Lk97yXoDgoOQhBSFENFlCqoK8l0yTEdDc5qtxS Authentication-Results: tana.it; auth=pass (details omitted) Original-From: Alessandro Vesely Original-Cc: IETF DMARC WG 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 00000000005DC026.000000005FC77663.00001400; Wed, 02 Dec 2020 12:11:31 +0100 To: Brandon Long Cc: IETF DMARC WG References: <8c83fffc-077d-9ddb-db2f-b9763361c60f@tana.it> <39eafc5e-3d9c-0bea-1173-7277070195ea@wisc.edu> <081c42a3-492b-89b7-ad76-ccec48dea091@tana.it> <2d1dca4f-e46a-646c-9fa3-d9ca56c72196@tana.it> From: Alessandro Vesely Message-ID: <01d1849f-6a0a-5307-db54-7587e33fc018@tana.it> Date: Wed, 2 Dec 2020 12:11:31 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] A policy for direct mail flows only, was ARC questions X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 02 Dec 2020 11:11:44 -0000 On Wed 02/Dec/2020 03:14:46 +0100 Brandon Long wrote: > On Tue, Dec 1, 2020 at 2:37 AM Alessandro Vesely wrote: >> On Tue 01/Dec/2020 05:56:46 +0100 Brandon Long wrote: >>> On Thu, Nov 26, 2020 at 12:59 AM Alessandro Vesely wrote: >>>> On 25/11/2020 20:16, Michael Thomas wrote: >>>>> On 11/25/20 11:11 AM, Alessandro Vesely wrote: >>>>>> On 25/11/2020 19:24, Jesse Thompson wrote: >>>>>>> On 11/25/20 11:30 AM, Alessandro Vesely wrote: >>>>>>>> Without resorting to ARC, it is still possible to validate author >>>>>>>> domain's signatures directly if the MLM just adds a subject tag >>>>>>>> and a footer>>>>> >>>>>>> I agree that ARC isn't really needed to do this (trust the last hop >>>>>>> from the MLM and determine the original authenticity from the MLM's >>>>>>> perspective)>>>> >>>>>> I didn't mean to trust the MLM. I meant remove the subject tag and >>>>>> the footer, then the original DKIM signature verifies. See: >>>>>> https://datatracker.ietf.org/doc/draft-vesely-dmarc-mlm-transform/ >>>>> >>>>> When I was at Cisco, with l= and some subject line heuristics I could get >>>>> probably like 90+% verification rate across the entire company, a company that >>>>> uses external mailing lists a lot. Definitely not 100% though. >>>> >>>> >>>> DKIM itself is not 100%. You always have lines beginning with "From " or >>>> occasional autoconversions. >>>> >>>> l= doesn't cover multipart/alternative nor Content-Transfer-Encoding: >>>> base64. In addition, the DKIM spec discourages its usage and suggests >>>> that "Assessors might wish to ignore signatures that use the tag.">> >>> >>> Right, some of the other dkim-light or diff concepts we discussed would be >>> better than using l= >>> >>> We again got hung up on the 100% solution, though... something that handled >>> subject-prefix and footer in a transport agnostic way might have worked. >> >> I'm not clear about the meaning of "100%". If an author domain puts no >> DKIM signatures, there is no way to verify them. Hence, some compliance of >> the author domain has to be required. >> >> The same holds for conditional signatures. >> >> The same holds for MLM transformations. >> > > Yes, by 100% I meant of messages that were already authenticated and > therefore should continue to be authenticated through the relay. That's ARC. If a message lacks DKIM and was SPF-authenticated, there's no way it can continue to be authenticated through a relay. OTOH, mailing lists and relays are two different beasts. For one thing, it is very unusual for a mailing list to send to another mailing list. Thus, we can safely specify a non-stackable authentication method. > Some of the conditional signatures of the "include a diff you can remove to > validate the original" attempt seemed to fail on the theory that there were > too many things that couldn't be handled. Ie, if your relay removes > attachments, including them back in a diff kind of breaks the whole point of > that... but how common is that (even less now with Yahoo Groups gone, but > possibly still some av/malware relays still do this). Not to mention anonymous lists, which remove the OP identity completely. They are DMARC-proof by themselves, with no additional twists. My draft restricts footers to text/plain MIME type, to overcome the objection to l=. Hence, if a list appends HTML parts (e.g. to use
), it doesn't qualify as DMARC-proof. > I think that one issue we've had is that DMARC is very mechanical and > straight-forward, so anything that's fuzzy in response seems more > complicated. It may seem fuzzy, but it's not. The ietf list (ietf@ietf.org), for example, adds no subject tag and no footer. DKIM signatures should remain valid, then. Yet, if posters sign Sender:, they fail. I wouldn't call that fuzziness. It is the very nature of the spec. If you sign Received:, no relay can hold your signature over. Best Ale -- From nobody Wed Dec 2 03:15: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 9DB1A3A128F for ; Wed, 2 Dec 2020 03:15:55 -0800 (PST) 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_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (4096-bit key) header.d=aegee.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JhQ-HXLeIkLD for ; Wed, 2 Dec 2020 03:15:53 -0800 (PST) Received: from mail.aegee.org (mail.aegee.org [144.76.142.78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6CCBB3A1114 for ; Wed, 2 Dec 2020 03:15:52 -0800 (PST) Authentication-Results: mail.aegee.org/0B2BFmQq2625855; auth=pass (LOGIN) smtp.auth=didopalauzov@aegee.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=aegee.org; s=k4096; t=1606907749; i=dkim+MSA-tls@aegee.org; bh=t08bBkM5LSlpruKHP/lSFg5YllR5M2jEziCL1QjXOI4=; h=Subject:From:To:Date:In-Reply-To:References; b=q8J7NlkXrbeudUF8N56mYXEXxWFC+kUVHuXZXa/8kMzKnW2y1gBF9P5BifkqZWBXK M75C8AjDVxDy6JUBKqqZdAQ4mFe9bvVhgFVuek0LIOBxfYytWUky6KSEzuFjTJZrG0 GOEhgYKhx/xMwiMn5UvR6TDAn7tcvEX588IQO3oOyRaZAVhZywWZrAljP9lqAUoHuq 1f3UUjG7ZGBKNnCjqevHpNcAfc3mhaUMNOOct1fqIgJKjn4FOOTZLWc4t5yW3rAhuI kS+gOCOJasB4sKPs2suLqk8tc5wlJeTWN5ZecU8S9qMXuAdacA+YEwpvoA+/VS2yR0 ClaTPGseQ8ybn5EqPFZbExnEjbkuA4z/Co8VQ/FUxBwZHiXWDLqRitBnYhFdUyVHLn ed5LAS0CMXqhgVkhxRG5gq0MQbRVA+u0KmNOMv8WgTnQgBjJUBRmmxjNwCjbj6OOmu MtKs2MVVnZ17gLr4+MtGseFgIpIWrM1qsKXiPMbFxUpmIv7xBTClhfvD+VCsI3JbWO huP/7YUSulMW3VBdqvusPNxLw29AGgYdd1URx9iVhlIreVOUgAE8yzoV3EEEIrVgs1 nCujGR6FWDkrr4U/Qxkj5W7MQ0Z4E7KiOypd3PgkWv09yjeV/bJlInsKc4psoeXoLX ujCU+4heMhtRgvUCDwafV28c= Authentication-Results: mail.aegee.org/0B2BFmQq2625855; dkim=none Received: from [192.168.1.99] (87.118.146.153.topnet.bg [87.118.146.153] (may be forged)) (authenticated bits=0) by mail.aegee.org (8.15.2/8.15.2) with ESMTPSA id 0B2BFmQq2625855 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Wed, 2 Dec 2020 11:15:49 GMT Message-ID: <02de3db94e77ddb37f329c2a886ddf90a2d3c597.camel@aegee.org> From: =?UTF-8?Q?=D0=94=D0=B8=D0=BB=D1=8F=D0=BD_?= =?UTF-8?Q?=D0=9F=D0=B0=D0=BB=D0=B0=D1=83=D0=B7=D0=BE=D0=B2?= To: Dave Crocker , John R Levine , dmarc@ietf.org Date: Wed, 02 Dec 2020 13:15:47 +0200 In-Reply-To: <2fc01257-3307-c453-18a0-bc423dccfe6a@gmail.com> References: <2fc01257-3307-c453-18a0-bc423dccfe6a@gmail.com> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.39.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] Ticket #39 - remove p=quarantine X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 02 Dec 2020 11:15:56 -0000 Hello, On Tue, 2020-12-01 at 15:55 -0800, Dave Crocker wrote: > On 12/1/2020 3:17 PM, John R Levine wrote: > > #39 proposes that we remove p=quarantine.  I propose we leave it > > in, > > even if it > > is not very useful, because trying to remove it would be too > > confusing. > > process, I suggest this issue gets some meaningful discussion.  My > email > archive indicates it hasn't gotten any discussion at all. This was discussed under the subject “Abolishing DMARC policy quarantine” in June 2019. There was no consensus. SMTP offers this distinciton and this is mirrored in DMARC. In particular, senders are free to publish p=quarantine and receipients are free to interpret it as p=reject. Senders can publish p=reject and receivers are free to interpret it as p=quarantine. Moreover, some destination addresses do not have the concepts of a quarantine. E.g an address that accepts commands for mailing lists managements. Such addresses can either accept or reject the message - there is no quarantine, so interpreting published p=quarantine as p=reject is feasible. Recalling the discussion from June 2019 I do not count on any different consensus, if it the discussion happens here again now. Greetings Дилян From nobody Wed Dec 2 03:46: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 C20BE3A131B for ; Wed, 2 Dec 2020 03:46:40 -0800 (PST) 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 RnwL-n2AsOpg for ; Wed, 2 Dec 2020 03:46:39 -0800 (PST) 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 36E6D3A1313 for ; Wed, 2 Dec 2020 03:46:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1606909596; bh=j3RPhgqjrZvr0FX+ASEDY6bI2Ykl/Rzjz+WaDVu/h3o=; l=471; h=To:References:From:Date:In-Reply-To; b=AbvdDOEhkRXFJetJlo/g3cx4jCQalpFhtHsGsmrXys9S2vEr+qP0Dzsp0K+s8QqWP gW/ZDET6m+VeU+2qCQp1D3wrTqfi7QR7BBC4GToKUyQuz57Y5GCEApoi/14xKPFyKx CLYh2oV2Cn0RkliH5f/oqBaOPjv5PERYX+Vx8SBt8/5ccVt0GZ0Lv/l5YS43i Authentication-Results: tana.it; auth=pass (details omitted) Original-From: Alessandro Vesely 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 00000000005DC02A.000000005FC77E9C.000017A6; Wed, 02 Dec 2020 12:46:36 +0100 To: dmarc@ietf.org References: <20201202021651.E8EE128C576A@ary.qy> From: Alessandro Vesely Message-ID: <35296652-8608-a616-abec-6e7269d77d20@tana.it> Date: Wed, 2 Dec 2020 12:46:36 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: <20201202021651.E8EE128C576A@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] Ticket #39 - remove p=quarantine X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 02 Dec 2020 11:46:41 -0000 On Wed 02/Dec/2020 03:16:51 +0100 John Levine wrote: > > I have no idea, my mail system just ignores it so I was wondering what > other people do. Zdkimfilter writes a prominent comment in the A-R field. It is up to the MDA to interpret it. The suggested interpretation is to set KEYWORDS='$Junk', which some MUAs interpret as displaying the message in some sort of quirks mode. p=quarantine is a useful option ans should be continued. Best Ale -- From nobody Wed Dec 2 05:18: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 E01253A13CF for ; Wed, 2 Dec 2020 05:18:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.097 X-Spam-Level: X-Spam-Status: No, score=-1.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, FREEMAIL_REPLY=1, HTML_MESSAGE=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 b1-A6oVxgUnb for ; Wed, 2 Dec 2020 05:18:11 -0800 (PST) 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 C19113A13CE for ; Wed, 2 Dec 2020 05:18:11 -0800 (PST) Received: by mail-qk1-x736.google.com with SMTP id y18so1060310qki.11 for ; Wed, 02 Dec 2020 05:18:11 -0800 (PST) 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=jTGw74IbFRY7oMj46cDbN+kBaQN7XT8WaapzhXRPGDc=; b=kYvX+1oHmCbIvhct4TGjPaQhn4PVt9AFqa54185yWdHB1fHm4r8mxgTpdGlGZIP2s9 lqMa2KI7hrNcw1DCoQoERG9d5Kefr7JQrPHiJSGho+JtiTUZdx5hpRVdxfrf6GIUIJoz uOyGUx2Hw1XBELWsZQ81+SRPMsdZ9uKfU/0sJrOGyO71a9P81is+XU37S3AsMNfEToKt AFcemeOj36kb9bChnkZ9ebELx7hth3qcASZ7sRifhi42RJSbMoxRQVSpf64mgWXk7zi7 YsdYYPr9a4sVNwmufGCnsplis6fByxeYvAhYDErnSfNijA+8HwEVCV1P3Dnw5fQs6+gA FeNA== 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=jTGw74IbFRY7oMj46cDbN+kBaQN7XT8WaapzhXRPGDc=; b=KjZQKBa1Y+UOfzda7Wl6SymKpTqPX+XGLK3LSFjbPosntfAYvsg8Y5K+FtLz/6dQ5Q NSquI7MIN7qlt1Z+Ziz2ccHiINhkwCjs4vfop4OaYzyKaPFYBuT1heBpirghneISlFQH p8e8x5/fT4tgz4VmiI7fsF7lMX1PEVpwwTXkSOin/H007twCzmIUPLyoqH7/Et72Vbxc 1rcU18nKE4IHfo5XbXo9ls6mg+ekjNIrAtINHwOW2aHscsys+clzl/VnowxYjswaTOS9 TLAVzu4NSzRF99qJOQ2Y6/PD1D0h+CEHA89Buzf6y5X/y7ZzQ0dxVKELqnK3NzvG/lB0 4zJw== X-Gm-Message-State: AOAM531ACwTv6HIEVAxYC90QlBk+yk02baGhGtKPa2iVlgbQZQ6hvGls /yDXXZCCx8PMyjxSFVDBJBDKUAGr6/1Tui6PP0xuQlLS X-Google-Smtp-Source: ABdhPJw4TJuf/xqSE6ACpCwATUPFVvAo+DPZE3xa459cXcAgMBKe6Zi2UU3ov34hQpZFZX4kFn1X/NHzDV9ONlnN6pY= X-Received: by 2002:a37:6805:: with SMTP id d5mr2419609qkc.66.1606915090391; Wed, 02 Dec 2020 05:18:10 -0800 (PST) MIME-Version: 1.0 References: <2fc01257-3307-c453-18a0-bc423dccfe6a@gmail.com> <065f9a15-d0fb-4564-376b-0c7036079488@gmail.com> In-Reply-To: <065f9a15-d0fb-4564-376b-0c7036079488@gmail.com> From: Dotzero Date: Wed, 2 Dec 2020 08:17:58 -0500 Message-ID: To: IETF DMARC WG Content-Type: multipart/alternative; boundary="00000000000025a65105b57b1363" Archived-At: Subject: Re: [dmarc-ietf] Ticket #39 - remove p=quarantine X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 02 Dec 2020 13:18:13 -0000 --00000000000025a65105b57b1363 Content-Type: text/plain; charset="UTF-8" You are absolutely correct. It also doesn't prevent direct domain abuse when someone uses snail mail. Michael Hammer On Tue, Dec 1, 2020 at 10:09 PM Dave Crocker wrote: > On 12/1/2020 7:01 PM, Dotzero wrote: > > DMARC does one thing and one thing only - It mitigates direct domain > > abuse. > > It mitigates direct domain abuse in the rfc5322.From field. > > It doesn't mitigate domain abuse anywhere else. > > d/ > > -- > Dave Crocker > dcrocker@gmail.com > 408.329.0791 > > Volunteer, Silicon Valley Chapter > American Red Cross > dave.crocker2@redcross.org > > --00000000000025a65105b57b1363 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
You are absolutely correct. It also doesn't preve= nt direct domain abuse when someone uses snail mail.

Michael Hammer

On Tue, Dec 1, 2020 at 10:09 PM Dave Crocker <dcrocker@gmail.com> wrote:
On 12/1/2020 7:01 PM, Do= tzero wrote:
> DMARC does one thing and one thing only - It mitigates direct domain <= br> > abuse.

It mitigates direct domain abuse in the rfc5322.From field.

It doesn't mitigate domain abuse anywhere else.

d/

--
Dave Crocker
dcrocker@gmail.com<= /a>
408.329.0791

Volunteer, Silicon Valley Chapter
American Red Cross
dave.crocke= r2@redcross.org

--00000000000025a65105b57b1363-- From nobody Wed Dec 2 06:09: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 1872A3A140B for ; Wed, 2 Dec 2020 06:09:06 -0800 (PST) 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 1jODAu68lMl1 for ; Wed, 2 Dec 2020 06:09:04 -0800 (PST) Received: from mail-pl1-x629.google.com (mail-pl1-x629.google.com [IPv6:2607:f8b0:4864:20::629]) (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 66C493A1405 for ; Wed, 2 Dec 2020 06:09:04 -0800 (PST) Received: by mail-pl1-x629.google.com with SMTP id s2so1174502plr.9 for ; Wed, 02 Dec 2020 06:09:04 -0800 (PST) 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=88eZg3kqw8BhfhyaXpot/CppGtil7WVk9BIJEkKUZ20=; b=EGlpUug6yM4U0LkZIFbmLMvf96cz/JuimF2pk6Auft2bkTGVy1e+NxUq1HAQnzS7Al /s46jNJpP3Bcl6M4bycdV1wnINDl9g1ugr8Jo26XFC2Mf/nJrx7VTddnM9LwNMxPuvuJ RlIm5tygeGALqQgX5gcVoxJS7cbnHVeQLxXM0z5aEh8AfldNSdfOwGSEo4uf+y8nYZxf S0BHQGhjbFqa6q2SuLSmi9Q83OY75j48enXsOLRt2H0WNpN4EcKVRlA1awj2T6v5QCEz y2wWeZ1Eea1u7UoB349FIe86u54JISzRWkBjc9eYPVB//bZgdlchmQwihb6h7gxnkOZy 6BdA== 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=88eZg3kqw8BhfhyaXpot/CppGtil7WVk9BIJEkKUZ20=; b=HPSXul/FoC56QQexE7eCLXUB32h3wvf9HMqfw/n0XOa4Jx/+ZuPLsceNxb0OfYjjzt Ka063bZGaw/S47CEz8ssniCPq7KvAG73pMQt2T85tOllQVuWTfdTDYQ7sHd6V7y3s3OW hgwFW2bb+wTlriiFWwTIGex+aGdVWXlLppJKbi9Mpzy0QeH4JZdQmUhA6sTFBNUTdO6D xEKWaxZ/XZZT1GU63dgdBM8+vqkRw+ZWGEPj8BBop8tDeTch/caTiU+eE6ECrXZlrkRM tjSZzIohx7ahiyQaf0D0p+CNFalTDhtGGq6C7bE53u09vVt3LgZbPXTenkWrYruueB71 OZZQ== X-Gm-Message-State: AOAM531rPoabXGB0rfkGpZQ5jP72vl6UsFTD/eKPoXR33XNaGtnTGeqe BQyVH1ldHcpdPzRcDAQUApfuTh7ZH4k= X-Google-Smtp-Source: ABdhPJyq3yTRADSHJQGzXYmhUmaVzKk6A70aoUwAsSraUyHjWysknYU0OWvkLu1eciYlLLVnupcGbA== X-Received: by 2002:a17:90a:7343:: with SMTP id j3mr51042pjs.51.1606918143384; Wed, 02 Dec 2020 06:09:03 -0800 (PST) Received: from [192.168.0.109] (c-24-130-62-181.hsd1.ca.comcast.net. [24.130.62.181]) by smtp.gmail.com with ESMTPSA id e2sm2037462pjv.10.2020.12.02.06.09.02 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 02 Dec 2020 06:09:02 -0800 (PST) To: Steven M Jones , dmarc@ietf.org References: <20201202021651.E8EE128C576A@ary.qy> <327860af-2fa7-63ee-4b89-6e7e383f3d53@crash.com> <2804da89-84d1-f601-9425-0b0d9baf6ae1@gmail.com> <1f6cae74-4eed-47f5-7249-e526bf1f5845@crash.com> From: Dave Crocker Message-ID: Date: Wed, 2 Dec 2020 06:09:00 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 MIME-Version: 1.0 In-Reply-To: <1f6cae74-4eed-47f5-7249-e526bf1f5845@crash.com> Content-Type: multipart/alternative; boundary="------------FF95140B1A1A3D731C176D81" Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] Ticket #39 - remove p=quarantine X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 02 Dec 2020 14:09:06 -0000 This is a multi-part message in MIME format. --------------FF95140B1A1A3D731C176D81 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 12/2/2020 1:55 AM, Steven M Jones wrote: > > hen he commanded the tide to halt)" -- the latter phrasing is just > /slightly/ too ponderous even for me... Does "requesting" really imply > control over the outcome, rather than the expression of a desire? > My point is that I think the language MUST NOT be cast as saying anything about receiver behavior.  Rather, it must only talk about the domain owner's assessment of message validity, or the like. >> I'd frankly recommend changing the labels for these expressions, but >> expect folk to argue that there is too much installed base and >> operational history. > > Ah, now maybe we're getting somewhere. But if you toss that notion > out, you have to follow up with an example or two. Which labels, and > changing them in what way? > Well, I share that view of accompanying obligation... when I can.  I couldn't think of a reasonable 'hook' for the language, in the previous message. But above, I see I wrote a perspective that might be useful: validity. So, perhaps, something like: *p*: Domain Owner Assessment Policy (plain-text; REQUIRED for policy records). Indicates the severity of concern the domain owner has, for mail using its domain but not passing DMARC validation. Policy applies to the domain queried and to subdomains, unless subdomain policy is explicitly described using the "sp" tag. This tag is mandatory for policy records only, but not for third-party reporting records (see Section 7.1 ). Possible values are as follows: *none*: The Domain Owner offers no expression of concern. *quarantine:* The Domain Owner considers such mail to be suspicious. It is possible the mail is valid, although the failure creates a significant concern. *reject: *The Domain Owner considers all such failures to be a clear indication that the use of the domain name is not valid.  See Section 10.3 for some discussion of SMTP rejection methods and their implications. d/ -- Dave Crocker dcrocker@gmail.com 408.329.0791 Volunteer, Silicon Valley Chapter American Red Cross dave.crocker2@redcross.org --------------FF95140B1A1A3D731C176D81 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 12/2/2020 1:55 AM, Steven M Jones wrote:

hen he commanded the tide to halt)" -- the latter phrasing is just /slightly/ too ponderous even for me... Does "requesting" really imply control over the outcome, rather than the expression of a desire?

My point is that I think the language MUST NOT be cast as saying anything about receiver behavior.  Rather, it must only talk about the domain owner's assessment of message validity, or the like.


I'd frankly recommend changing the labels for these expressions, but expect folk to argue that there is too much installed base and operational history.

Ah, now maybe we're getting somewhere. But if you toss that notion out, you have to follow up with an example or two. Which labels, and changing them in what way?

Well, I share that view of accompanying obligation... when I can.  I couldn't think of a reasonable 'hook' for the language, in the previous message.

But above, I see I wrote a perspective that might be useful:  validity.

So, perhaps, something like:

p: Domain Owner Assessment Policy (plain-text; REQUIRED for policy records). Indicates the severity of concern the domain owner has, for mail using its domain but not passing DMARC validation. Policy applies to the domain queried and to subdomains, unless subdomain policy is explicitly described using the "sp" tag. This tag is mandatory for policy records only, but not for third-party reporting records (see Section 7.1). Possible values are as follows:

none: The Domain Owner offers no expression of concern.

quarantine: The Domain Owner considers such mail to be suspicious. It is possible the mail is valid, although the failure creates a significant concern.

reject: The Domain Owner considers all such failures to be a clear indication that the use of the domain name is not valid.  See Section 10.3 for some discussion of SMTP rejection methods and their implications.

d/

-- 
Dave Crocker
dcrocker@gmail.com
408.329.0791

Volunteer, Silicon Valley Chapter
American Red Cross
dave.crocker2@redcross.org
--------------FF95140B1A1A3D731C176D81-- From nobody Wed Dec 2 06:13: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 825493A1411 for ; Wed, 2 Dec 2020 06:13:49 -0800 (PST) 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 cSKsO26z5qBu for ; Wed, 2 Dec 2020 06:13:48 -0800 (PST) Received: from mail-pg1-x531.google.com (mail-pg1-x531.google.com [IPv6:2607:f8b0:4864:20::531]) (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 665B73A0A81 for ; Wed, 2 Dec 2020 06:13:48 -0800 (PST) Received: by mail-pg1-x531.google.com with SMTP id w4so1127619pgg.13 for ; Wed, 02 Dec 2020 06:13:48 -0800 (PST) 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=VTS/ZyC/K+YZ1JRoBmUtoWxYujtYm72ILVz6UtTId7c=; b=atHplQfVLjaLk6Fsuo0H3V43pkaGeUulnvPlrsMi4YcAK+GGM7uS0AS5OqgGhvJ9J2 WEELaPc6VmkOFgUTfnje3+vcTGhxPaB+b1zZxmf51AQNaaryPv2FqFLMz1KSZpE7+6wX z1MkZVRIyeuTuSxwSR6TEnRNyUhHnb8jsLcG/y/v3gadLWF6deAJ/fINLC1RHOvYwskS FwU36x9JEA2gaSBNDSDv8CWwwg6KBv1GVO+HmaQT/Eiz38refdnghMbeYuW0Chupat7V NUpm9xZBd9L41y0/PqxYBRQkfwFnbxZvP34aGBPgWlAnxCK0iAZV3xpihe1WUwS3UwQz KUMA== 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=VTS/ZyC/K+YZ1JRoBmUtoWxYujtYm72ILVz6UtTId7c=; b=N7Ho0vhBg1kjWJ612JQM02B3ZaeKFMf+qJdHn21i8McD/NqxHteYDCv9YL7mRefoXC kTt7lF/tn0MZniWGI2RZtd3RrF5i6aw0PgjG9i0A1wCSJnLWXnjbzooli8EUVk6SCnPj tmGyYwdOT3exRmkAlMEoGrsmlPI+x3kmJpAogJPDIIBA3omunNkRrollaFP3drT4WNGR AGWsvno8zQMtRyTK6K0pwUjwXaSKHqU/9Xj0qIqSjyTZMDEIewdRphZylNITlk8VPfoO O6FzVZST4UiCWNkqlxLEBGDQNFnE+O60OsaK/oyBybRW8rw1aQbdCoQLmgeV56BHLIwf 7rLA== X-Gm-Message-State: AOAM530Tg4Z9w0TqCs7FIc/SsnNNgH+S8eYJOP3bvw1RZcy6XZxcdfea WvBXlQbMtNW8JaqGM7MpS6N+waDl7oE= X-Google-Smtp-Source: ABdhPJz0QrgmzdvPz6/YSGJ3xdKTFblEJz8MLFaAoIQkFPRvUBl68/axsLBxwHQH6MnPMxXwqfVJXQ== X-Received: by 2002:a63:b60:: with SMTP id a32mr48020pgl.275.1606918427669; Wed, 02 Dec 2020 06:13:47 -0800 (PST) Received: from [192.168.0.109] (c-24-130-62-181.hsd1.ca.comcast.net. [24.130.62.181]) by smtp.gmail.com with ESMTPSA id c3sm32851pgm.41.2020.12.02.06.13.46 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 02 Dec 2020 06:13:46 -0800 (PST) To: Dotzero , IETF DMARC WG References: <2fc01257-3307-c453-18a0-bc423dccfe6a@gmail.com> <065f9a15-d0fb-4564-376b-0c7036079488@gmail.com> From: Dave Crocker Message-ID: Date: Wed, 2 Dec 2020 06:13:44 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.5.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] Ticket #39 - remove p=quarantine X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 02 Dec 2020 14:13:50 -0000 On 12/2/2020 5:17 AM, Dotzero wrote: > You are absolutely correct. It also doesn't prevent direct domain > abuse when someone uses snail mail. I suppose, with some effort, you could have offered an even less useful example.  But since I was being quite serious about the qualification I offered and since it's important to be clear about DMARC's scope of utility, a more useful example is that DMARC does nothing about use of the domain name anywhere else in a message. Not the display name, not the Subject line and not the Body. As mitigation of direct abuse goes, that means that DMARC's scope of mitigation is impressively narrow. For most things involving significant threats, such a narrow effect would not comfortably be described with the implication of such a broader scope as you (and others) use. d/ -- Dave Crocker dcrocker@gmail.com 408.329.0791 Volunteer, Silicon Valley Chapter American Red Cross dave.crocker2@redcross.org From nobody Wed Dec 2 06:18: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 D754D3A1416 for ; Wed, 2 Dec 2020 06:18:27 -0800 (PST) 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 Nq_4fvOh3vbT for ; Wed, 2 Dec 2020 06:18:26 -0800 (PST) Received: from mail-pl1-x635.google.com (mail-pl1-x635.google.com [IPv6:2607:f8b0:4864:20::635]) (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 B744C3A1415 for ; Wed, 2 Dec 2020 06:18:26 -0800 (PST) Received: by mail-pl1-x635.google.com with SMTP id bj5so1197962plb.4 for ; Wed, 02 Dec 2020 06:18:26 -0800 (PST) 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=bNQKlqywWXVvuxaFAsFBfc1uHtb7Y+QnVf584je47C0=; b=PJZrrdK2FwWgULUildYkvhT3nMWtIqUHFmxBRLlxmHACuMgxjXoI/njvQ02I0WH1u8 oKT++fapg1CPllhfiPxIWCarq826lVOQxJPe/KTrdd3rGxTEee71lagqdpDUo4yaDhqh ZdJ23eiCgpSL26Nkq3Yo6v45YX7J6cM6EX+YN2PlStPESJZYipcCYZcQ2OMosu1SgjIq PBOG6eIg7lD4OXO2jCtlg+S0PYSy+/SdeAFoW9NmmvOqZbGJOBEtKNtyXMzmhRsoUWtJ MuZbj3axJK/rYhHUC9x9ytyXdZaZQMBpoqxjzF8+IaXNdDpeSnFG3DsCvO8fa7g8e4C9 HAMA== 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=bNQKlqywWXVvuxaFAsFBfc1uHtb7Y+QnVf584je47C0=; b=UqGYTB96v3rSXVzuI1OQj/hiWDDpg2vnGjYMaAWvEuRfIDVtqwUBdkdJFCom766shF VvfAfoFnxCjHrbp37Zdm2hFRaSejG+WqEtLm5uzMH/j37BljB+eO8siFKJFLA+Rb4eBI ebYY3XCkiC4X16haKsvMn8wETFN/LRWvDktD251YREF6M5FGa2TjarbWQFQvJAf779Yv YRp3EXAUeUeHRZJbKny8PZkrAWIuLM4jXsM9aDsC2b0SqoVcCIebYauq/N8uPV3iKf3b B0+/90yumxTkaOsGR4ZpYTlionhUZ3aloA87MTQwd/iaLvwq/d8rY6gEiWqHs35ic/GJ K+Gg== X-Gm-Message-State: AOAM532r1u7+gaNAa97CvEQ1UywfTXFMAZGBiKwkZUyGYp2Sgj63vjK3 e4mxjZehyp/K39A9MGIDULydStc6NrM= X-Google-Smtp-Source: ABdhPJwaIFnOI4rdrZ03CtIKcP+GW4qz6r8SrlkgrxFErLwysUzdWVanHZpy7zD531UsIVhBwAbeNg== X-Received: by 2002:a17:90a:1b41:: with SMTP id q59mr93501pjq.17.1606918706103; Wed, 02 Dec 2020 06:18:26 -0800 (PST) Received: from [192.168.0.109] (c-24-130-62-181.hsd1.ca.comcast.net. [24.130.62.181]) by smtp.gmail.com with ESMTPSA id js9sm2290957pjb.2.2020.12.02.06.18.25 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 02 Dec 2020 06:18:25 -0800 (PST) To: =?UTF-8?B?0JTQuNC70Y/QvSDQn9Cw0LvQsNGD0LfQvtCy?= , John R Levine , dmarc@ietf.org References: <2fc01257-3307-c453-18a0-bc423dccfe6a@gmail.com> <02de3db94e77ddb37f329c2a886ddf90a2d3c597.camel@aegee.org> From: Dave Crocker Message-ID: Date: Wed, 2 Dec 2020 06:18:22 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 MIME-Version: 1.0 In-Reply-To: <02de3db94e77ddb37f329c2a886ddf90a2d3c597.camel@aegee.org> Content-Type: multipart/alternative; boundary="------------CA52E0BDAD4C416AB08ED65E" Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] Ticket #39 - remove p=quarantine X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 02 Dec 2020 14:18:28 -0000 This is a multi-part message in MIME format. --------------CA52E0BDAD4C416AB08ED65E Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 12/2/2020 3:15 AM, Дилян Палаузов wrote: > On Tue, 2020-12-01 at 15:55 -0800, Dave Crocker wrote: >>  My email archive indicates it hasn't gotten any discussion at all. > This was discussed under the subject “Abolishing DMARC policy > quarantine” in June 2019. I see that was quite a lengthy thread.  Thanks for the research. My assessment was based on looking for the cited ticket number. d/ -- Dave Crocker dcrocker@gmail.com 408.329.0791 Volunteer, Silicon Valley Chapter American Red Cross dave.crocker2@redcross.org --------------CA52E0BDAD4C416AB08ED65E Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 12/2/2020 3:15 AM, Дилян Палаузов wrote:
On Tue, 2020-12-01 at 15:55 -0800, Dave Crocker wrote:
 My email archive indicates it hasn't gotten any discussion at all. 
This was discussed under the subject “Abolishing DMARC policy
quarantine” in June 2019.


I see that was quite a lengthy thread.  Thanks for the research.  My assessment was based on looking for the cited ticket number.

d/

-- 
Dave Crocker
dcrocker@gmail.com
408.329.0791

Volunteer, Silicon Valley Chapter
American Red Cross
dave.crocker2@redcross.org
--------------CA52E0BDAD4C416AB08ED65E-- From nobody Wed Dec 2 06:28: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 3B0BC3A1225 for ; Wed, 2 Dec 2020 06:28:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.651 X-Spam-Level: X-Spam-Status: No, score=-1.651 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_HELO_NONE=0.001, SPF_PASS=-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 Wiwd3jTaf14H for ; Wed, 2 Dec 2020 06:28:47 -0800 (PST) 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 84C203A1224 for ; Wed, 2 Dec 2020 06:28:47 -0800 (PST) Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1kkT7d-0008m3-Ul for dmarc@ietf.org; Wed, 02 Dec 2020 15:28:45 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: dmarc@ietf.org From: Benny Lyne Amorsen Date: Wed, 02 Dec 2020 15:28:41 +0100 Message-ID: <87y2ig9t9i.fsf@orion.amorsen.dk> References: <20201202021651.E8EE128C576A@ary.qy> <327860af-2fa7-63ee-4b89-6e7e383f3d53@crash.com> <2804da89-84d1-f601-9425-0b0d9baf6ae1@gmail.com> <1f6cae74-4eed-47f5-7249-e526bf1f5845@crash.com> Mime-Version: 1.0 Content-Type: text/plain User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) Cancel-Lock: sha1:+8ctcWOdCqR1oDRI0VUkIlOxGUA= Archived-At: Subject: Re: [dmarc-ietf] Ticket #39 - remove p=quarantine X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 02 Dec 2020 14:28:49 -0000 Dave Crocker writes: > p: Domain Owner Assessment Policy (plain-text; REQUIRED for policy > records). Indicates the severity of concern the domain owner has, for > mail using its domain but not passing DMARC validation. Policy > applies to the domain queried and to subdomains, unless subdomain > policy is explicitly described using the "sp" tag. This tag is > mandatory for policy records only, but not for third-party reporting > records (see Section 7.1). Possible values are as follows: > > none: The Domain Owner offers no expression of concern. > > quarantine: The Domain Owner considers such mail to be suspicious. It > is possible the mail is valid, although the failure creates a > significant concern. > > reject: The Domain Owner considers all such failures to be a clear > indication that the use of the domain name is not valid. See Section > 10.3 for some discussion of SMTP rejection methods and their > implications. Perhaps, in retrospect, the p= should have had something like the following values: none untrustworthy invalid p= mistakenly chose to use the language of receiver actions to describe what is actually domain-owner judgements. This is unfortunate, since it risks making the sender believe that it is possible to dictate receiver policy. Perhaps new names can be found, and the old ones kept as historical aliases? /Benny From nobody Wed Dec 2 06:32: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 857F83A1246 for ; Wed, 2 Dec 2020 06:32:15 -0800 (PST) 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 QhDOuimmsXpu for ; Wed, 2 Dec 2020 06:32:13 -0800 (PST) Received: from mail-pf1-x432.google.com (mail-pf1-x432.google.com [IPv6:2607:f8b0:4864:20::432]) (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 BCCFC3A1225 for ; Wed, 2 Dec 2020 06:32:13 -0800 (PST) Received: by mail-pf1-x432.google.com with SMTP id 131so1347584pfb.9 for ; Wed, 02 Dec 2020 06:32:13 -0800 (PST) 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=TxNUATTUGLJBOJfxlmYkOzNsjnB+h/MCXPyN8zUdMAU=; b=fgt4xChsgmXuRYpHfKO0jeDFfbjWf5e+r8ONGMrxW71mKCQkfS1VZB+O8jHOpPf7Vf vo+5vNCLpG4MO4r0KycP9XD5QWRz0qi08I65rnwbuirq9+Kteu1RBr+2R6MdOhHn+1Ao KrwMiiH8PNVnms1qEjwBR7srPjEUOKzLo3+d+hkNuBB6j6H0IkL/F0tM5iMvtbRPj6nN LHW2q/+kq6Hncxw4URSRAt0FvfSAn6L6/a/l+GsO6LSdFy8wBDuiBurgEjIeAS3sIm8p JMs//kmv95aOFsVmP/z7EZH16MQul1wE8nhhVagLsKj/pocJmdvxnXWR/7a+yP7SQoz1 6hpg== 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=TxNUATTUGLJBOJfxlmYkOzNsjnB+h/MCXPyN8zUdMAU=; b=jLA7lVn1b27OzrR5v2MKknduqITnC2nOlE5UoPQQoujrg9Ux2WVXnx9cxH/youoVUk iLGaoJNb8Q+10mWLcgrWtAd3x8ii72JHBFTYJWF9YsnwmyIwCakn/cWQ95x2wWEHaIv1 Vn5r6GY+ICFLW/MmrRJm11ju8xM1TxY1Y+iveD+xSFUv+aV724nxgH+uOO+IwWac79Tz 8DJ0CoYl7SBg0iXEBjmmO3fDruBxImBpdEImLl9CTie5SzkjTMKTIidZo7J9PIk6lPnh ERGHP7qww8u03akp74ExH2zeRcaMQLtsfSs8lakE++gFUA2TDWGPNnWWAf/kUSeu0QK5 5Xxw== X-Gm-Message-State: AOAM531bsYujuVirXC3OOaZCU+TBAnDvS8EjlVDK8mgQvthxFdguMWrt s8QV42lY2CWbIs6faPdn4PgO1ox8j5M= X-Google-Smtp-Source: ABdhPJwX95159RSnxD6l6EoSAgDC9pKxETlLn4lUA6c/CPuggw4tNHC/f+k4boEiWbLtm+WwP44VwA== X-Received: by 2002:a62:83cf:0:b029:18c:76a1:755 with SMTP id h198-20020a6283cf0000b029018c76a10755mr2859542pfe.22.1606919532725; Wed, 02 Dec 2020 06:32:12 -0800 (PST) Received: from [192.168.0.109] (c-24-130-62-181.hsd1.ca.comcast.net. [24.130.62.181]) by smtp.gmail.com with ESMTPSA id s30sm74066pgl.39.2020.12.02.06.32.11 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 02 Dec 2020 06:32:11 -0800 (PST) To: Benny Lyne Amorsen , dmarc@ietf.org References: <20201202021651.E8EE128C576A@ary.qy> <327860af-2fa7-63ee-4b89-6e7e383f3d53@crash.com> <2804da89-84d1-f601-9425-0b0d9baf6ae1@gmail.com> <1f6cae74-4eed-47f5-7249-e526bf1f5845@crash.com> <87y2ig9t9i.fsf@orion.amorsen.dk> From: Dave Crocker Message-ID: <8c60030d-048d-f7ef-cf99-08329b407569@gmail.com> Date: Wed, 2 Dec 2020 06:32:09 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 MIME-Version: 1.0 In-Reply-To: <87y2ig9t9i.fsf@orion.amorsen.dk> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] Ticket #39 - remove p=quarantine X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 02 Dec 2020 14:32:16 -0000 On 12/2/2020 6:28 AM, Benny Lyne Amorsen wrote: > Perhaps, in retrospect, the p= should have had something like the > following values: > > none > untrustworthy > invalid > > p= mistakenly chose to use the language of receiver actions to describe > what is actually domain-owner judgements. This is unfortunate, since it > risks making the sender believe that it is possible to dictate receiver > policy. > > Perhaps new names can be found, and the old ones kept as historical > aliases? Yes!  I would deeply wish we could change the vocabulary to something like this. However I'd expect too much persistence, due to operational history.  Still, it would be really nice if the working group could convince itself to specify a better vocabulary. d/ -- Dave Crocker dcrocker@gmail.com 408.329.0791 Volunteer, Silicon Valley Chapter American Red Cross dave.crocker2@redcross.org From nobody Wed Dec 2 06:47: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 AD1FE3A1435 for ; Wed, 2 Dec 2020 06:47:22 -0800 (PST) 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 WL4Z6tEDNHXV for ; Wed, 2 Dec 2020 06:47:21 -0800 (PST) Received: from mail-qv1-xf36.google.com (mail-qv1-xf36.google.com [IPv6:2607:f8b0:4864:20::f36]) (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 CC2DE3A1434 for ; Wed, 2 Dec 2020 06:47:20 -0800 (PST) Received: by mail-qv1-xf36.google.com with SMTP id es6so778205qvb.7 for ; Wed, 02 Dec 2020 06:47:20 -0800 (PST) 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=Cv2K6IwFrDOb3u+331cqvpPaHgsJ1Hx0ndghSjvFSGY=; b=kuqabQECw+arthsbR+YWNAaysJi07Y+dU6Mm2rBd8inhZBzPNuCbYkvAwwUaSpx+3H cMjXZ9FDZF4nw9nJyyLBMpVDYd59kOVoqicP5zlEchpGMR3AmWP1Q2laCMgKz3+Qsphs 5lCun+OKyFUP2DHqmH4+6JdD3fDMIOwZ3DYHWTDCbzBgSPKThH2CTC9OpYBeTTL1n+RP m22/s6c0bWbbVpWa/elwk4EBz49DBKBB+zcIxQD6iYF06HwQX5LoaDp+DV7Gw8/Ftf0A 8oT2tXAwPaCRyT8jdxXGn94ydjhzH2VMcbHHPr5m/fGbw8wvrQzQna7EieWHIqbaTyJU OKOg== 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=Cv2K6IwFrDOb3u+331cqvpPaHgsJ1Hx0ndghSjvFSGY=; b=neLFKUpCZQptsDwaSwU49vz1CpC9mA0y7n0i7dAcJvtB39P7DE+A3dWDi0zNyIWe5a HSnnXgpg0fstd2Eu6+AmW+uXbnbWDb0mPVOj/lzuVGL3CxuUE5SSR2nBXPXb1NaT/JZE JAEh7h78LJeDVXRReMBB4pAfwXfAVDMCvnMki08xuBSvwtfUQ/62oZjf8H1GgOWDRbez RRYM18OOI1BzqVH+aPi9sH2dqHT25PjxGHMfM5qWnSgb2vGCaOPfU2GYTNV8FfDe++4i QR/pmkIYKRn5KHAwb85iOz+84rRHvc3irHwS+W70o+MGkzm8p+5uyp8d6HEwnmwUCBNr dz3g== X-Gm-Message-State: AOAM533FOZKf4EMe/lYeZbifh4Z2yrcW/tMGGPJKmbBkOPRKhebo6+Ip MjggxisXq+ixbI4vo2/jnT+f/mBV3/h6jcMX8ZcHGMJ0 X-Google-Smtp-Source: ABdhPJzR9Xg6n6y1vezB9RbCcX0ZOx1C5rxCf20ixsomXQnBUljLe4WAvfUqSVfx3y5c4qE3Nt8LCd4UraZrWRFuuzI= X-Received: by 2002:ad4:5762:: with SMTP id r2mr2891900qvx.45.1606920439767; Wed, 02 Dec 2020 06:47:19 -0800 (PST) MIME-Version: 1.0 References: <20201202021651.E8EE128C576A@ary.qy> <327860af-2fa7-63ee-4b89-6e7e383f3d53@crash.com> <2804da89-84d1-f601-9425-0b0d9baf6ae1@gmail.com> <1f6cae74-4eed-47f5-7249-e526bf1f5845@crash.com> <87y2ig9t9i.fsf@orion.amorsen.dk> In-Reply-To: <87y2ig9t9i.fsf@orion.amorsen.dk> From: Dotzero Date: Wed, 2 Dec 2020 09:47:07 -0500 Message-ID: To: Benny Lyne Amorsen Cc: IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000fea99205b57c51d8" Archived-At: Subject: Re: [dmarc-ietf] Ticket #39 - remove p=quarantine X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 02 Dec 2020 14:47:23 -0000 --000000000000fea99205b57c51d8 Content-Type: text/plain; charset="UTF-8" On Wed, Dec 2, 2020 at 9:29 AM Benny Lyne Amorsen wrote: > Dave Crocker writes: > > > p: Domain Owner Assessment Policy (plain-text; REQUIRED for policy > > records). Indicates the severity of concern the domain owner has, for > > mail using its domain but not passing DMARC validation. Policy > > applies to the domain queried and to subdomains, unless subdomain > > policy is explicitly described using the "sp" tag. This tag is > > mandatory for policy records only, but not for third-party reporting > > records (see Section 7.1). Possible values are as follows: > > > > none: The Domain Owner offers no expression of concern. > > > > quarantine: The Domain Owner considers such mail to be suspicious. It > > is possible the mail is valid, although the failure creates a > > significant concern. > > > > reject: The Domain Owner considers all such failures to be a clear > > indication that the use of the domain name is not valid. See Section > > 10.3 for some discussion of SMTP rejection methods and their > > implications. > > Perhaps, in retrospect, the p= should have had something like the > following values: > > none > untrustworthy > invalid > > p= mistakenly chose to use the language of receiver actions to describe > what is actually domain-owner judgements. This is unfortunate, since it > risks making the sender believe that it is possible to dictate receiver > policy. > > p= DID NOT mistakenly choose to use the language of receiver actions. p= represents the domain-owner request to the receiver as to the disposition of messages which fail to validate. Any reading of "concern" is supposition on the part of yourself or other self appointed interpreters of the mind of the domain-owner or administrator. The vocabulary is perfectly fine as it accurately describes the request being made. It makes no attempt to read the underlying reasoning behind the request because, surprisingly, there is likely to be a wide range of underlying reasoning behind why various domains publish the policies they publish. This is an interoperability standard, not a seance. Michael Hammer --000000000000fea99205b57c51d8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Dec 2, 2020 at 9:29 AM Benny = Lyne Amorsen <benny+usenet@= amorsen.dk> wrote:
Dave Crocker <dcrocker@gmail.com> writes:

>=C2=A0 p: Domain Owner Assessment Policy (plain-text; REQUIRED for poli= cy
>=C2=A0 records). Indicates the severity of concern the domain owner has= , for
>=C2=A0 mail using its domain but not passing DMARC validation. Policy >=C2=A0 applies to the domain queried and to subdomains, unless subdomai= n
>=C2=A0 policy is explicitly described using the "sp" tag. Thi= s tag is
>=C2=A0 mandatory for policy records only, but not for third-party repor= ting
>=C2=A0 records (see Section 7.1). Possible values are as follows:
>
>=C2=A0 none: The Domain Owner offers no expression of concern.
>
>=C2=A0 quarantine: The Domain Owner considers such mail to be suspiciou= s. It
>=C2=A0 is possible the mail is valid, although the failure creates a >=C2=A0 significant concern.
>
>=C2=A0 reject: The Domain Owner considers all such failures to be a cle= ar
>=C2=A0 indication that the use of the domain name is not valid.=C2=A0 S= ee Section
>=C2=A0 10.3 for some discussion of SMTP rejection methods and their
>=C2=A0 implications.

Perhaps, in retrospect, the p=3D should have had something like the
following values:

none
untrustworthy
invalid

p=3D mistakenly chose to use the language of receiver actions to describe what is actually domain-owner judgements. This is unfortunate, since it
risks making the sender believe that it is possible to dictate receiver
policy.


p=3D DID NOT mistakenly choose to use = the language of receiver actions. p=3D represents the domain-owner request = to the receiver as to the disposition of messages which fail to validate. A= ny reading of "concern" is supposition on the part of yourself or= other self appointed interpreters of the mind of the domain-owner or admin= istrator. The vocabulary is perfectly fine as it accurately describes the r= equest being made. It makes no attempt to read the underlying reasoning beh= ind the request because, surprisingly, there is likely to be a wide range o= f underlying reasoning behind why various domains publish the policies they= publish. This is an interoperability standard, not a seance.
Michael Hammer
--000000000000fea99205b57c51d8-- From nobody Wed Dec 2 08:22: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 E31F13A1391 for ; Wed, 2 Dec 2020 08:22:40 -0800 (PST) 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 XtRAgvh7_eAO for ; Wed, 2 Dec 2020 08:22:39 -0800 (PST) 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 EC2433A146E for ; Wed, 2 Dec 2020 08:22:13 -0800 (PST) Received: by mail-qt1-x82d.google.com with SMTP id k4so1402478qtj.10 for ; Wed, 02 Dec 2020 08:22:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=EVFLOiK00CdzLS7m3e7qQUf/j728An/XGQ8igoUeklI=; b=Ty1SPQTztib718kUPn+Uc1PG6DVCP6yV/NbwMSI+GOGggX8ZNWp8tMyaEJkMAOByBT i7Tt4Sq9JRVZ5jYPoO5oJ5EcR64Itjn0aAN4XCJeojnY0leQC77QRd4eAdD+83VsvkWX olnR5CG+W1uAbVxIi5dfYen2yHSjLVBN8c+B35WbYDDNWL/wpPPqmjymw5Pj4MXJod8m ua5v9B/rc3rJRJUoD3sl/YonfI4f0uPICkM+w0Gr55LDTlyrDqKFWiRmsFOYWP/oEB7p G9G0obMhoVld/4QySTdLjeS7BsyivVTfFe/CLpMC1dOMVU9jYtly/zJ3ZgjeyGPs134T USBQ== 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=EVFLOiK00CdzLS7m3e7qQUf/j728An/XGQ8igoUeklI=; b=X5rz/jGI7xLU/ZZT6Lsz1X25hdgDZO2Qc9u+F51A5ftWX1XtvJdjKxzeNqGgtZNSSM Y7YgEXChA46KlxplvZmY6LsZbens8u6AkdsZzIQGxB+Cuca9xQ0WqvxFP/YBl7Gwf7R8 7/pEMWXE19ZTU39mDVj12OLty05CzGxt4q+8ghVN4JKYMqpY8lOz/+90IfwKgzMw6huY N0GfbntCPWwKkxp8HwE4DZbAW6L3N1Q35boqomka4hisf92lm8ldbFHXNfXfoW5J2mjy LsSMVO+F2VkMj/B5RGfovmY6vtzAS+PjGUicWn3qCGLTuy1McKup9tHeTS4GcKvMowBk IBsA== X-Gm-Message-State: AOAM532i88EPKu+bsKpP46pZVT2Vpa5MNoN02jXCtcfGyUI/CcsRuHes pqZXGMohtGIai/f2C46xfeV6IkjxmUIOubzuR77dpMfsgtQ= X-Google-Smtp-Source: ABdhPJyzbFN00sXIUG318H2LzY4dDRCN2gviQe98ZQnSVPlEM24cc966mohihcjeBlj/3qMxvGHzNRrdq3ccpQUmmWU= X-Received: by 2002:a05:622a:14e:: with SMTP id v14mr3314191qtw.298.1606926132685; Wed, 02 Dec 2020 08:22:12 -0800 (PST) MIME-Version: 1.0 References: <20201202025026.F16E128C5FDE@ary.qy> In-Reply-To: <20201202025026.F16E128C5FDE@ary.qy> From: Todd Herr Date: Wed, 2 Dec 2020 11:21:57 -0500 Message-ID: To: IETF DMARC WG Content-Type: multipart/alternative; boundary="00000000000051c32c05b57da576" Archived-At: Subject: Re: [dmarc-ietf] Domains and tree walk X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 02 Dec 2020 16:22:41 -0000 --00000000000051c32c05b57da576 Content-Type: text/plain; charset="UTF-8" On Tue, Dec 1, 2020 at 9:50 PM John Levine wrote: > In organizations that are not universities, the entity that > is responsible for the registered domain generally sets policies for > the whole organization, and a good deal of the DMARC design is there > to let them figure out who is sending mail with their name on it from > any of their subdomains and identify and adjust senders whose mail > doesn't match the policy. > > This is, I think, one of the most underappreciated features of DMARC. With p=none, a proper rua= value, and enough time, one can collect all the information needed to address any authentication shortcomings within a designated portion of the DNS namespace before moving forward to p=reject, assuming that that is one's goal with a DMARC implementation. Even for less lofty goals such as ensuring that all mail is properly DKIM signed, or that the SPF record properly enumerates all mail sources, I can't think of a better tool than DMARC aggregate reports for ferreting out that third party that the Marketing department hired to send mail on the company's behalf, or locating that one mail stream emanating from the "server" sitting at the side of Eddie the Engineer's desk. -- *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. --00000000000051c32c05b57da576 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Tue, Dec 1, 2020 at 9:50 PM John Levin= e <johnl@taugh.com<= /a>> wrote:
= =C2=A0In organizations that are not universities, the entity that
is responsible for the registered domain generally sets policies for
the whole organization, and a good deal of the DMARC design is there
to let them figure out who is sending mail with their name on it from
any of their subdomains and identify and adjust senders whose mail
doesn't match the policy.


This = is, I think, one of the most underappreciated features of DMARC. With p=3Dn= one, a proper rua=3D value, and enough time, one can collect all the inform= ation=C2=A0needed to address any authentication shortcomings within a desig= nated portion of the DNS namespace before moving=C2=A0forward to p=3Dreject= , assuming that that is one's goal with a DMARC implementation. Even fo= r less lofty goals such as ensuring that all mail is properly DKIM signed, = or that the SPF record properly enumerates all mail sources, I can't th= ink of a better tool than DMARC aggregate reports for ferreting out that th= ird party that the Marketing department hired to send mail on the company&#= 39;s behalf, or locating that one mail stream emanating from the "serv= er" sitting at the side of Eddie the Engineer's desk.
<= div>
--


This email= and all data transmitted with it contains confidential and/or proprietary = information intended solely for the use of individual(s) authorized to rece= ive it. If you are not an intended and authorized recipient you are hereby = notified of any use, disclosure, copying or distribution of the information= included in this transmission is prohibited and may be unlawful. Please im= mediately notify the sender by replying to this email and then delete it fr= om your system.

--00000000000051c32c05b57da576-- From nobody Wed Dec 2 11:08: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 A312A3A155E for ; Wed, 2 Dec 2020 11:08:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.089 X-Spam-Level: X-Spam-Status: No, score=-2.089 tagged_above=-999 required=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_PASS=-0.001, T_SPF_HELO_TEMPERROR=0.01] 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 4hiQ78PSb4DA for ; Wed, 2 Dec 2020 11:08:25 -0800 (PST) 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 A19723A1570 for ; Wed, 2 Dec 2020 11:08:25 -0800 (PST) Received: by mail-ua1-x92c.google.com with SMTP id y21so549448uag.2 for ; Wed, 02 Dec 2020 11:08:25 -0800 (PST) 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=DRKjKSYcoklqhGd8GolCez4vv3Udzssysfvz+eF91BY=; b=VmKhVi9o/DEks2PaRz6Hgl64wYdn0SRIiaW/dECMvpzu1gkb5mTbk2zBsnzVhxmqX7 3u0LtUMYwN7103HhGOWT2g2SofIbnzAIPIYFwBe745veSbAXxOtCzlQrZmCFuemzmXXH 1gj1zo4FjxVGUn4LMM/zM2rK/p7SxNRGfBumPfT/D+bmuFCFNJUijPl67WonY1U6HfMI 9c2UY1fT1+XH5fmNgs6qIt09/YO7cT4cXS0jJRyDkOBxyXGo6CELcAK90/GC59wE9V5/ fBC+Ip/ETyD23jabqd1WxXe2lXG9mVpu/9egvmyvUTutUTcNnRNGDRfQ+UH169JxD17W RabA== 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=DRKjKSYcoklqhGd8GolCez4vv3Udzssysfvz+eF91BY=; b=DzigZTqmsb8oviNql88QIX+nIoC8NITCrb26gMsm3yTxOqZqfV5YrxtC56kMzAeo6g 50MYsXQPqM2Y/FjWcVOMobRwKx8X2dhcDII+bzYBAC4AvkIhEf2ZuXuelILE5qd698xq zDoYek14YyE31WZt0vUXlzS+bUonSWdfOguJls5dTccmVAR7vQq/1wPDsKdzPpxy+cCd ZuU2YsT+Rp0cYylezVtSr8omSjRx0K6iQwzT81Lwsu3mB2xU/sxCqen9n9LppWYxWQNT /c+gfdKyvIbfsoIf8stsGe60q8fMxiciX/s1vHcSpLRszmrjrrk/UpOhvKJcp+Im+SK3 khng== X-Gm-Message-State: AOAM533emRFPVNJqGpTWA3u4G/X63ueihR1AF+DbbaKHSJmQE7lFPF5L TCvtgfzFEXCm5hVXJr5LAYZ3QMK90R2hnWJXlTw= X-Google-Smtp-Source: ABdhPJz/0OUCpLg+2oNmpkKEVUcZlCeGyKAUtXTie8J91tt5PMepF+C8x/heDcs861lQXwiw85sWL2Uxl+rvYNN44Vc= X-Received: by 2002:ab0:36a7:: with SMTP id v7mr3102990uat.67.1606936104577; Wed, 02 Dec 2020 11:08:24 -0800 (PST) MIME-Version: 1.0 References: <20201202021651.E8EE128C576A@ary.qy> <327860af-2fa7-63ee-4b89-6e7e383f3d53@crash.com> <2804da89-84d1-f601-9425-0b0d9baf6ae1@gmail.com> <1f6cae74-4eed-47f5-7249-e526bf1f5845@crash.com> <87y2ig9t9i.fsf@orion.amorsen.dk> In-Reply-To: From: "Murray S. Kucherawy" Date: Wed, 2 Dec 2020 11:08:13 -0800 Message-ID: To: Dotzero Cc: Benny Lyne Amorsen , IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000b0b14605b57ff77a" Archived-At: Subject: Re: [dmarc-ietf] Ticket #39 - remove p=quarantine X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 02 Dec 2020 19:08:38 -0000 --000000000000b0b14605b57ff77a Content-Type: text/plain; charset="UTF-8" On Wed, Dec 2, 2020 at 6:47 AM Dotzero wrote: > p= DID NOT mistakenly choose to use the language of receiver actions. p= > represents the domain-owner request to the receiver as to the disposition > of messages which fail to validate. Any reading of "concern" is supposition > on the part of yourself or other self appointed interpreters of the mind of > the domain-owner or administrator. The vocabulary is perfectly fine as it > accurately describes the request being made. It makes no attempt to read > the underlying reasoning behind the request because, surprisingly, there is > likely to be a wide range of underlying reasoning behind why various > domains publish the policies they publish. This is an interoperability > standard, not a seance. > Not sure I agree. I have long held a quiet dislike for "quarantine" because that has a particular meaning to milter implementations. Specifically, milter can render one of several final results about a message, one of which is actually called "quarantine". It means "park this in the queue indefinitely until a human decides what to do with it." There's no indication to the operator that such a job is waiting for review unless one goes and looks for such things. The upshot of this is that quarantining in that environment can become a denial of service attack if I send you enough messages that end up getting handled that way and your queue disk fills, or the queue takes an inordinately long time to process because these have piled up and need to be inspected. Certainly not all implementers will trip on this (maybe none will) but it's an argument to me in favor of picking a word or set of words that describe what the domain owner thinks of the message, rather than what the domain owner thinks you should do with it. -MSK (hatless) --000000000000b0b14605b57ff77a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Dec 2, 2020 at 6:47 AM Dotzero &l= t;dotzero@gmail.com> wrote:
=
p=3D DID NOT mistakenly choose to use the language= of receiver actions. p=3D represents the domain-owner request to the recei= ver as to the disposition of messages which fail to validate. Any reading o= f "concern" is supposition on the part of yourself or other self = appointed interpreters of the mind of the domain-owner or administrator. Th= e vocabulary is perfectly fine as it accurately describes the request being= made. It makes no attempt to read the underlying reasoning behind the requ= est because, surprisingly, there is likely to be a wide range of underlying= reasoning behind why various domains publish the policies they publish. Th= is is an interoperability standard, not a seance.

Not sure I agree.

I have long hel= d a quiet dislike for "quarantine" because that has a particular = meaning to milter implementations.=C2=A0 Specifically, milter can render on= e of several final results about a message, one of which is actually called= "quarantine".=C2=A0 It means "park this in the queue indefi= nitely until a human decides what to do with it."=C2=A0 There's no= indication to the operator that such a job is waiting for review unless on= e goes and looks for such things.=C2=A0 The upshot of this is that quaranti= ning in that environment can become a denial of service attack if I send yo= u enough messages that end up getting handled that way and your queue disk = fills, or the queue takes an inordinately long time to process because thes= e have piled up and need to be inspected.

Certainl= y not all implementers will trip on this (maybe none will) but it's an = argument to me in favor of picking a word or set of words that describe wha= t the domain owner thinks of the message, rather than what the domain owner= thinks you should do with it.

-MSK (hatless)
<= /div>
--000000000000b0b14605b57ff77a-- From nobody Wed Dec 2 11:27: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 351923A0AAD for ; Tue, 1 Dec 2020 05:27:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=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 hfllaG4-fL1Z for ; Tue, 1 Dec 2020 05:27:29 -0800 (PST) Received: from www210.your-server.de (www210.your-server.de [78.46.0.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 82AAD3A0A87 for ; Tue, 1 Dec 2020 05:27:28 -0800 (PST) Received: from sslproxy01.your-server.de ([78.46.139.224]) by www210.your-server.de with esmtpsa (TLSv1.3:TLS_AES_256_GCM_SHA384:256) (Exim 4.92.3) (envelope-from ) id 1kk5gk-0001FV-Go for dmarc@ietf.org; Tue, 01 Dec 2020 14:27:26 +0100 Received: from [109.190.207.208] (helo=[192.168.1.60]) by sslproxy01.your-server.de with esmtpsa (TLSv1.3:TLS_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kk5gk-000EN1-DI for dmarc@ietf.org; Tue, 01 Dec 2020 14:27:26 +0100 To: dmarc@ietf.org References: <8c83fffc-077d-9ddb-db2f-b9763361c60f@tana.it> <39eafc5e-3d9c-0bea-1173-7277070195ea@wisc.edu> <081c42a3-492b-89b7-ad76-ccec48dea091@tana.it> <2d1dca4f-e46a-646c-9fa3-d9ca56c72196@tana.it> From: devel2020@baptiste-carvello.net Message-ID: <127cca11-1fef-b75c-65ca-aa7119e295d5@baptiste-carvello.net> Date: Tue, 1 Dec 2020 14:27:04 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: fr Content-Transfer-Encoding: 8bit X-Authenticated-Sender: webmaster@baptiste-carvello.net X-Virus-Scanned: Clear (ClamAV 0.102.4/26004/Mon Nov 30 15:29:06 2020) Archived-At: X-Mailman-Approved-At: Wed, 02 Dec 2020 11:27:16 -0800 Subject: Re: [dmarc-ietf] A policy for direct mail flows only, was ARC questions X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 01 Dec 2020 13:27:31 -0000 Le 01/12/2020 à 11:37, Alessandro Vesely a écrit : > > [...] a meagre set of old-fashioned individuals who still dislike mass social media [...] Can decisions please be made based on sound technical reasons rather than intolerance and zealotry? Setting aside the form of your argument: no, contracting with Facebook et al should not be a prerequisite for using the Internet for any purpose. By the very definition of "open network". Cheers, BC From nobody Wed Dec 2 11:29: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 D74AD3A1532 for ; Wed, 2 Dec 2020 11:29:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.65 X-Spam-Level: X-Spam-Status: No, score=-1.65 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, 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=mtcc-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bqTCVIHV-q_F for ; Wed, 2 Dec 2020 11:29:22 -0800 (PST) Received: from mail-pl1-x62d.google.com (mail-pl1-x62d.google.com [IPv6:2607:f8b0:4864:20::62d]) (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 559393A152F for ; Wed, 2 Dec 2020 11:29:22 -0800 (PST) Received: by mail-pl1-x62d.google.com with SMTP id j1so136060pld.3 for ; Wed, 02 Dec 2020 11:29:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mtcc-com.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=BDf2PMO9e9Q2ToaJBvqkzjR9Q/pKLnMzmivHnOowypY=; b=ZGYjrMghhx9MUpBCAfvbVbBeXCwaxgAGBq4ru7RQGfkOVUIB3gsL1I+w/5Q4Er/qhj 6l8d2vz7xDX/Utgl2XlMO/E0DprmwRM7BEuwkFkKjfdL1Dc2McfY6xPFcUC/o8i5sk03 XFv+QQ6rpAt9hYDc7pnppxXTVQMaGzzJgTqX4ttrxjEMGOYzJDsVLY2J3aSVT8vZast6 baI1GX5dpPb2EJKSYZ9F2uuL0fVJ023ZFiF+ICjCZr0x+cP5q6YIAFzoO0NT4VkayhqP pMEwHkxKjXBzsXrmuzXZotL5PUEAYQICG5AdGZXbHLSaloHGJBit9jO5zpM/8XuuZBrf Pn2w== 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=BDf2PMO9e9Q2ToaJBvqkzjR9Q/pKLnMzmivHnOowypY=; b=eNb+S2YU9PS7vllh2V1T80YVdE15Ir3LBAU/qm71EejSMCNRn2eXbAANhILTSrx4bu PISIIo8MnE8VtugZHkSLVcWJWotx4DvvZNYEPZcyqVfs4ptM+ScCPuKjwb8FPqpoIlJt A/yShUnK9drl85AOda6PtFnCprO061JfqGpAVL0I/NiU6YJig3WMZ0NxDTYHaIaZIivf m5Eb0OQLR88xhp6/GO5+l4OKdIM/PUGuG4A9pVYCR0JEWtymPVA2wWLspESwnrmi5JU3 Kbax1s/3KCsEVPQAQwbr4ivT7TRYTJB9ZzathsdaPMrV5L/aJUI2ku3svLFzVDotqOha v32Q== X-Gm-Message-State: AOAM533Ex406AFsw+5gT0EnvGxW4s32oh6JFWePMDsTGbcoNNNYC9k5p m5Sri1beg+qosNdVQH0GUiEwqbfLSwnGRA== X-Google-Smtp-Source: ABdhPJy/6H/xipwt/g4d0zt9RWcaswG/0KlMr+pAEaXnxZN2Jw4oeVuuBWXHGb1RGXArtOiBTqIhZg== X-Received: by 2002:a17:902:b688:b029:d9:d374:68d with SMTP id c8-20020a170902b688b02900d9d374068dmr3924991pls.9.1606937361219; Wed, 02 Dec 2020 11:29:21 -0800 (PST) Received: from mike-mac.lan (107-182-42-33.volcanocom.com. [107.182.42.33]) by smtp.gmail.com with ESMTPSA id o2sm461330pgi.60.2020.12.02.11.29.19 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 02 Dec 2020 11:29:20 -0800 (PST) To: Brandon Long Cc: IETF DMARC WG References: <8c83fffc-077d-9ddb-db2f-b9763361c60f@tana.it> <39eafc5e-3d9c-0bea-1173-7277070195ea@wisc.edu> <081c42a3-492b-89b7-ad76-ccec48dea091@tana.it> <2d1dca4f-e46a-646c-9fa3-d9ca56c72196@tana.it> <8353c6ab-adac-d0c2-a809-1384aac9b39f@mtcc.com> From: Michael Thomas Message-ID: Date: Wed, 2 Dec 2020 11:29:19 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------A4CF2E28D2B7BB7C1CABB370" Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] A policy for direct mail flows only, was ARC questions X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 02 Dec 2020 19:29:24 -0000 This is a multi-part message in MIME format. --------------A4CF2E28D2B7BB7C1CABB370 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 12/1/20 6:21 PM, Brandon Long wrote: > > > On Tue, Dec 1, 2020 at 10:07 AM Michael Thomas > wrote: > > > On 11/30/20 8:56 PM, Brandon Long wrote: >> Right, some of the other dkim-light or diff concepts we discussed >> would be better than using l= >> >> We again got hung up on the 100% solution, though... something >> that handled subject-prefix and >> footer in a transport agnostic way might have worked.  The fact >> that DKIM isn't transport agnostic >> is an achilles heel to even that, though, since we'd have to come >> up with a new canonicalization >> and get it to widespread adoption before the simple diff could >> work.  Or require mailing lists to >> be a lot more strict in how they do their email rewriting, but I >> imagine that's harder work than >> even ARC. >> > Frankly all it would take is a google or another large mail > provider to publicly state that unless a mailing list supports BCP > XYZ, your mail will be subject to very strict scrutiny and likely > not delivered to get the attention of mailing list providers. That > was my suggestion back in the day but it was scoffed at because > people could point to some edge case that generates .001% of list > traffic and thus invalidating the entire approach. The best is > definitely the enemy of the good here. > > People really need to keep in mind that service provider email is > not the only game in town. That point keeps getting lost. > > arguably we're all here because a large mail provider did make such a > change (though to be fair, there were plenty of others who wanted to > make that change). > > While Google might be able to help move things along, there would need > to be strong community support for that, no one wants to go this alone > and look like the big bully. > > I also think that you're overestimating what we could do. Ultimately, > we serve our customers, and they want their legitimate email, even if > it doesn't support BCP XYZ. > Well obviously the BCP would have to come first and there would have to be community buy-in to create such a BCP, but a Google participating in creating such a BCP ought pique the interests of people who make mailing list software who obviously have the biggest stake in this. It occurs to me that it might not even be a BCP. Maybe mailing lists can just create a header with sed commands to undo its changes :) Mike --------------A4CF2E28D2B7BB7C1CABB370 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit


On 12/1/20 6:21 PM, Brandon Long wrote:


On Tue, Dec 1, 2020 at 10:07 AM Michael Thomas <mike@mtcc.com> wrote:


On 11/30/20 8:56 PM, Brandon Long wrote:
Right, some of the other dkim-light or diff concepts we discussed would be better than using l= 

We again got hung up on the 100% solution, though... something that handled subject-prefix and
footer in a transport agnostic way might have worked.  The fact that DKIM isn't transport agnostic
is an achilles heel to even that, though, since we'd have to come up with a new canonicalization
and get it to widespread adoption before the simple diff could work.  Or require mailing lists to
be a lot more strict in how they do their email rewriting, but I imagine that's harder work than
even ARC.

Frankly all it would take is a google or another large mail provider to publicly state that unless a mailing list supports BCP XYZ, your mail will be subject to very strict scrutiny and likely not delivered to get the attention of mailing list providers. That was my suggestion back in the day but it was scoffed at because people could point to some edge case that generates .001% of list traffic and thus invalidating the entire approach. The best is definitely the enemy of the good here.

People really need to keep in mind that service provider email is not the only game in town. That point keeps getting lost.

arguably we're all here because a large mail provider did make such a change (though to be fair, there were plenty of others who wanted to make that change).

While Google might be able to help move things along, there would need to be strong community support for that, no one wants to go this alone and look like the big bully.

I also think that you're overestimating what we could do.  Ultimately, we serve our customers, and they want their legitimate email, even if it doesn't support BCP XYZ. 


Well obviously the BCP would have to come first and there would have to be community buy-in to create such a BCP, but a Google participating in creating such a BCP ought pique the interests of people who make mailing list software who obviously have the biggest stake in this.

It occurs to me that it might not even be a BCP. Maybe mailing lists can just create a header with sed commands to undo its changes :)

Mike

--------------A4CF2E28D2B7BB7C1CABB370-- From nobody Wed Dec 2 11:48: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 0249B3A16B2 for ; Wed, 2 Dec 2020 11:47:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fqd3ijUY4IUj for ; Wed, 2 Dec 2020 11:47:52 -0800 (PST) Received: from mx0b-00143702.pphosted.com (mx0b-00143702.pphosted.com [148.163.141.77]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C9F83A1628 for ; Wed, 2 Dec 2020 11:47:34 -0800 (PST) Received: from pps.filterd (m0184890.ppops.net [127.0.0.1]) by mx0b-00143702.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 0B2Jhd3V019516 for ; Wed, 2 Dec 2020 14:47:33 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.com; h=from : to : subject : date : message-id : content-type : content-transfer-encoding : mime-version; s=20190412; bh=3rzbGdEO8jd7xm5e9D7ujwguaOK3ojFwRIHPuKn+1/E=; b=4rdxGmo0eQ0gJwy+6uIHBloJmhyep7/mWwsn7ppXbOrVv97l1QmAHHeYTI2VA5kmGOPp NysMAjn17BtkCu1pR+M1n6wHbTHl9irwizhS8vQibCGyLP/mmX2pzNnpHyElGciImJ1W GmMc98w3YtKhH8s/L3X28j7Xx+z0RizrXmCMlZERRn7g7m/jJO2Xx29njV1bNUYS1WbE z9IY4AkdnriF83XPkJ5J4NKrLcpmQZI8o5yCu1KcbrAGY/5L67yQHxvd/7izcjiNP08t 1yb+2fSPV8671eg0MEoHC5C2DFtn6ol1MBnU3mE6O48/sCEKTHbC87t1d9IN6pzt2W4N fA== Received: from copdcexc39.cable.comcast.com (dlppfpt-po-1p.slb.comcast.com [96.99.226.137]) by mx0b-00143702.pphosted.com with ESMTP id 353khm37jt-13 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for ; Wed, 02 Dec 2020 14:47:33 -0500 Received: from copdcexc33.cable.comcast.com (147.191.125.132) by copdcexc39.cable.comcast.com (147.191.125.138) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1713.5; Wed, 2 Dec 2020 12:47:15 -0700 Received: from COPDCEXEDGE01.cable.comcast.com (96.114.158.213) by copdcexc33.cable.comcast.com (147.191.125.132) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1713.5 via Frontend Transport; Wed, 2 Dec 2020 12:47:15 -0700 Received: from NAM10-MW2-obe.outbound.protection.outlook.com (104.47.55.108) by webmail.comcast.com (96.114.158.213) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 2 Dec 2020 14:46:58 -0500 Received: from MN2PR11MB4351.namprd11.prod.outlook.com (2603:10b6:208:193::31) by BL0PR11MB3188.namprd11.prod.outlook.com (2603:10b6:208:61::27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3632.17; Wed, 2 Dec 2020 19:46:54 +0000 Received: from MN2PR11MB4351.namprd11.prod.outlook.com ([fe80::7ca6:b482:a6b0:4d42]) by MN2PR11MB4351.namprd11.prod.outlook.com ([fe80::7ca6:b482:a6b0:4d42%7]) with mapi id 15.20.3611.025; Wed, 2 Dec 2020 19:46:54 +0000 From: "Brotman, Alex" To: "dmarc@ietf.org" Thread-Topic: Discussion - ARC/Extensible Reporting (Ticket #56) Thread-Index: AdbI4+CbIMDOrFacSCuqUWajtLQ8Tw== Date: Wed, 2 Dec 2020 19:46:54 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=comcast.com; x-originating-ip: [2601:43:101:380:6512:4f2e:142a:b350] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 3d81f55d-9c1c-4d0d-902b-08d896fb056b x-ms-traffictypediagnostic: BL0PR11MB3188: 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: 3b5mi4gsItFygndsDUcITkBHcMQBIbzSMuhNW3n5owk8ti1axdCsAgkvwXWWZi06JATVc/8b0cRyAq/yHd/GFWGAlXJL9q5ELBFDSMN0nP00fK9tGawpCj2WKt5n3BaFv3faGcVSm5p9iU/0tipJwyaTdH704xWtIuaoPRr8mxzXvd0HbKYdIMOQlokCQhNwWam0hDdThPOcKuTkEwvSil9OVxSwasx1LoH3Q0X+4zz7NL69iIUVtoNml5T9aivbgmEi4Cm30kEWyGKAm9UMoe5bl03GJiFH9XTuiYQlfKONGsQ2yADmQEr0jhx7OVlR x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR11MB4351.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(39860400002)(376002)(396003)(346002)(136003)(33656002)(71200400001)(2906002)(86362001)(316002)(8936002)(8676002)(478600001)(52536014)(55016002)(66446008)(66946007)(76116006)(66476007)(66556008)(64756008)(186003)(5660300002)(7696005)(4744005)(9686003)(6506007)(6916009)(83380400001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: =?us-ascii?Q?7m89JtkZ1IwUf/OTwttouv68nKqdR1IWJqg4wvjJcF/CovXlpQLWRoUOMaeq?= =?us-ascii?Q?hACjBQVyQ7DC/EKympf6iTldeSwJEEc5g+0X5qabWilvB7liYtkfVu8jvoDD?= =?us-ascii?Q?nalCHZcOPlT8XPYO2l9nltn/7Omwb33osKEI/dpLs7gy9QidN9AqoDqGmaQJ?= =?us-ascii?Q?r7yWdfBruTQep8lIZYlj0N7sxdI+2TX/mr+i2o5DuuHyLM3O6zHcDY1SaNtS?= =?us-ascii?Q?c9JbKkgZ+Ls7vB8z31EK8gSMybR1RPQV358Rp98tZAq5Eg1v2qv44EE1ZdQS?= =?us-ascii?Q?x+Dc7DZPx+r/89fY4kjMxKmtXA4ZofhIMhEPndGOnFtOxIjJvZwZi8hUhfzv?= =?us-ascii?Q?9zKp9preo35CjHcaWGlmmfaqjuOzvLoYVb7Av6iBOvwgt501s+u6ClHvVn9L?= =?us-ascii?Q?64fUHZ9DLhzJOZz5wK7SNgfwV5zYfqvPQjGJCCMH5AlYVhI79GutfmepqLmC?= =?us-ascii?Q?3bo6fQdjyJ3sEV0gWSb9XNUxTdI7jiKCLzYpvkK8wc0mtoJcTEW51WrQOEWi?= =?us-ascii?Q?DaR0J3JQOd74GNSF8oyjW/j+K1nO9fBVow+ZoBhBEz/i/0ql7mCu4liDt5OY?= =?us-ascii?Q?ZPVsea56ItdOVXUtkbf54ZMfBPNNgG2mdotj4i7nIA9n++uWGBo7W/CjWX6J?= =?us-ascii?Q?G9F48Z5eaHPI8lkVZN5F2v9+aji67RHePF3nh9gHglgblhhKbHQ261IGQL/W?= =?us-ascii?Q?PI/8sXeEtsrXkKxUtArTNVymNdRCKpmKyXcwzvD+uy5yipRuuwPModglbmPN?= =?us-ascii?Q?CYy1+QbcJu/KAk7FNNTyTbx9rooxQUZpl/mpt/4BQwgiHBY8qlPoRW+gDYW9?= =?us-ascii?Q?Dn91udPuILYRK/18LotGw/v1gRBZWV89Oj9SfXAUMLEtmOoaHV9AJD1dBJkI?= =?us-ascii?Q?oNEQrQmblLu94plRvZWmGG46BrM/L7Dfz0QdHsLRXGPDwhDZcPubj5gR747k?= =?us-ascii?Q?tydG3TTv+jP17jvrNXZHBgx5NgVakMQIl114iLHGYXrSRvEyzJZH5Vo7hOUm?= =?us-ascii?Q?IMxglrUYR08v0J/5jCKI4Q5flyt0NBGSw380A1b9FNiOGa8=3D?= x-ms-exchange-transport-forked: True arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=dsRYbWNMkWeBRvo37sJkPeYhoaaWusG4hHb/0z4+pFreXs1cUuA3mWMQy5a5zxh2TTRRRcOUCBB5Kbk4w6KvgnQVGlpagoJGM/KkVJ9plnZsj0ItxNLe068Fd1fUqRbFB1Pp3yknGY+rOGUpRPqqdIKyPKuUvSygc3vYmuJN9+2yaA/FZvra5qjKo2y/DMsS7/qLicXpwUw+yz8lXv/laZt33sswcQpVHLvGRULrRoTYxdrtX0YLQSGTvXoNJO9EElO9THC0vt4PLcwSMOGQX1VPREUyHEyJZRW9AyVgiLAMSrkwm1+cKRDpRCaLDGwGpWOzngistfkRVw7GozzYuw== 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=3DJcgX5W7B+0aQ+3ah+dO34jHWm97/4Uzmq+5E2euMs=; b=TfzzrFL4U7AK5gwcWiqBLkMFKyb98UMBSGX9kK+uVaMlbyBAUVP8go7ZIifUuIBuvZq7jBdFDw9P88O0Z+FCKVMS4xtKjiLaQi0rNM/yAJEmLXheKofN9HhGcnXfa20NYqFGbdjFXXRrue/N6QvpsPzujGhVcAzuCJzMLuhURUF3fszT8zxwyXbVNCfmTb/thXdxjnpy4GX/y0us4DBl832v8HoLssPruBGmBkrwajK5nsgDtWx8xzK1/F0bYoYSbTIwYZ+2sIbLnv9/+Tkh6H2bCfwyNY8rrliYSVvJ/zrTPbph4Qami23xS9FlT70k86h20N65PjoqcscDfJNjPQ== arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=comcast.com; dmarc=pass action=none header.from=comcast.com; dkim=pass header.d=comcast.com; arc=none x-ms-exchange-crosstenant-authas: Internal x-ms-exchange-crosstenant-authsource: MN2PR11MB4351.namprd11.prod.outlook.com x-ms-exchange-crosstenant-network-message-id: 3d81f55d-9c1c-4d0d-902b-08d896fb056b x-ms-exchange-crosstenant-originalarrivaltime: 02 Dec 2020 19:46:54.4188 (UTC) x-ms-exchange-crosstenant-fromentityheader: Hosted x-ms-exchange-crosstenant-id: 906aefe9-76a7-4f65-b82d-5ec20775d5aa x-ms-exchange-crosstenant-mailboxtype: HOSTED x-ms-exchange-crosstenant-userprincipalname: y89OAD+Em3QeDr/TlzUzY15X81T/H8XXENt+v8TdCsyvRkompa3sDO//T4wlzzJWxqCoV1gNOcvk1+/t+5+vl42NnoRJ4dtzulvRB6M21FY= x-ms-exchange-transport-crosstenantheadersstamped: BL0PR11MB3188 x-originatororg: comcast.com Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Forward AAETWT X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.312, 18.0.737 definitions=2020-12-02_12:2020-11-30, 2020-12-02 signatures=0 X-Proofpoint-Spam-Reason: safe Archived-At: Subject: [dmarc-ietf] Discussion - ARC/Extensible Reporting (Ticket #56) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 02 Dec 2020 19:48:02 -0000 Folks, While this ticket/enhancement specifically mentions ARC, I could perhaps se= e the usefulness in other places. It seems like it would be more beneficia= l to create a method by which other documents could provide XML- based "ext= ensions" to the report. This would allow mechanisms relying on DMARC to in= dependently define their reporting schema to be included in DMARC aggregate= reports. Alternately, we could focus specifically on ARC, and work to inc= lude that in the base XML. This means that any later reporting requirement= s could again require changes to the core drafts. If possible, we'd like to see if we can reach some consensus within a few w= eeks. -- Alex Brotman Sr. Engineer, Anti-Abuse & Messaging Policy Comcast From nobody Wed Dec 2 11:48: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 C63F43A1766 for ; Wed, 2 Dec 2020 11:48:46 -0800 (PST) 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 aeEE1KCDd2-I for ; Wed, 2 Dec 2020 11:48:45 -0800 (PST) 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 8A8573A15DD for ; Wed, 2 Dec 2020 11:48:14 -0800 (PST) Received: by mail-ua1-x92e.google.com with SMTP id y21so588229uag.2 for ; Wed, 02 Dec 2020 11:48:14 -0800 (PST) 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=9qt76ysejWl7nq2ZYAbXrYIqZeMzbFwQrh93/6hE1n8=; b=Ue26aYeYxKXQ5O1ENShCeqS4YxvKQZ4zF4PdsgZ2cXcWdA2Sxg1ECu9o2QV7fDnolx JdMHj0XhguUWRy9IgCRy6UcZQVpSK0AGW5a2tlNUyRfkBxdTMoX57LDq/h3mKdO5zoas Kelu6lrg/xfcDBZiciJidFH2Eqsjf20zTdPa6ZwUp3ECLOrygLk+6zCm2/Z8ZULhmEKP NH2UJ0UxgUvjmZvIMQp6v3gcJHTiZwWtEX2DBfGIfDO4PVXTCbfb6KypIM6cvyurqOjj N/R3ggIw4yhA7RODXRlY7ABqoFiHSHE1r3uxuO5sKCIzylHIzMFK2sLNQZYpS/z8t1rj amSQ== 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=9qt76ysejWl7nq2ZYAbXrYIqZeMzbFwQrh93/6hE1n8=; b=EH9b+sS3q1jgu91FFVH0sDwifwB/3I2MDGsIODMzZsUlOgSCEdkAIwo8waLlyBSu62 eSX7xm0S3O1N9kTNGQDojsynH5/m23hjtmkpZ0q+hX/cSaBn4leHCqTbbZHyxCTkphbY NiJipvaqebXeSApctSSOO2qm6xqVgcXHPUZPC4v/weGQIjMmpy+FlKaUiembFbW4z+zm NwlmmAecgjwhdmRV4YT8zS768ZsfIvwItP7VxriBdcDpZu8vqsBppkM/DnzCORmYSVi5 AV+736F11miM31s7SR4d4sO36LFrhxSV6uZcSD2cZRfUVdOqTDbU49SlsW+bKIsXHHFB gkNA== X-Gm-Message-State: AOAM531X9oBls1XBYQf3FErasw9y2drh9fn9DkOZEhIPHBMQFAgB5DkC pUMLTGHynJcCBe9ohvcQFfk2rt/MUaJBV0mWmOs= X-Google-Smtp-Source: ABdhPJyllX9Cat9oWFJauu8X6FFPlopdXsQE8QpfWuZANvxIiqTFlsd4lGwehS4rg2z4KEwesUw78qe/qwbAPFq9tCE= X-Received: by 2002:ab0:2e9:: with SMTP id 96mr2859099uah.87.1606938493461; Wed, 02 Dec 2020 11:48:13 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: "Murray S. Kucherawy" Date: Wed, 2 Dec 2020 11:48:02 -0800 Message-ID: To: Joseph Brennan Cc: IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000142b4005b58086bb" Archived-At: Subject: Re: [dmarc-ietf] 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, 02 Dec 2020 19:48:54 -0000 --000000000000142b4005b58086bb Content-Type: text/plain; charset="UTF-8" On Tue, Dec 1, 2020 at 5:44 PM Joseph Brennan wrote: > I want to ask again why DMARC should consider any domain other than > the one in the Header From. The purpose of DMARC should be stated > right at the top of the proposed standard. It is intended to control > use of a domain in the Header From. If the Header From has > blabla@example.com, the DMARC record for _dmarc.example.com should > apply. > > It does not make sense to me to say that if the Header From is > user@alpha.example.com, and there is no _dmarc.alpha.example.com > record, then recipient systems should continue to look for > _dmarc.example.com and apply the dmarc rule there. I know of no other > standard that requires this type of relationship. This is something > new. It will require administrators to continually check what their > sub- and supra-domains are doing in order to escape interference by > DMARC records they did not create. I think this is unreasonable. Only > domains interested in applying DMARC should be involved with DMARC. > Others should be able to do what they want. I know that otherwise will > out rule out DMARC for the "columbia.edu" domain that I administer. > If DMARC is thus constrained and you have a "p=reject" on "columbia.edu" only, then nothing stops me from generating unauthenticated email with a >From field indicating "foobar.columbia.edu" for any subdomain "foobar", whether or not it actually exists in the DNS. -MSK --000000000000142b4005b58086bb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Dec 1, 2020 at 5:44 PM Joseph Bre= nnan <brennan@columbia.edu&g= t; wrote:
I want to ask again why DMARC should consider any doma= in other than
the one in the Header From. The purpose of DMARC should be stated
right at the top of the proposed standard. It is intended to control
use of a domain in the Header From. If the Header From has
blabla@example.com<= /a>, the DMARC record for _dmarc.example.com should
apply.

It does not make sense to me to say that if the Header From is
user@alpha.exam= ple.com, and there is no _dmarc.alpha.example.com
record, then recipient systems should continue to look for
_= dmarc.example.com and apply the dmarc rule there. I know of no other standard that requires this type of relationship. This is something
new. It will require administrators to continually check what their
sub- and supra-domains are doing in order to escape interference by
DMARC records they did not create. I think this is unreasonable. Only
domains interested in applying DMARC should be involved with DMARC.
Others should be able to do what they want. I know that otherwise will
out rule out DMARC for the "columbia.edu" domain that I administer.=

If DMARC is thus constrained and you h= ave a "p=3Dreject" on "colum= bia.edu" only, then nothing stops me from generating unauthenticat= ed email with a From field indicating "foobar.columbia.edu" for any subdomain "foobar",= whether or not it actually exists in the DNS.

-MSK
--000000000000142b4005b58086bb-- From nobody Wed Dec 2 12:13: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 EE3513A1550 for ; Wed, 2 Dec 2020 12:13:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.65 X-Spam-Level: X-Spam-Status: No, score=-1.65 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, 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=mtcc-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2ahATtv24AJE for ; Wed, 2 Dec 2020 12:13:48 -0800 (PST) Received: from mail-pf1-x433.google.com (mail-pf1-x433.google.com [IPv6:2607:f8b0: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 0F3C33A1568 for ; Wed, 2 Dec 2020 12:13:47 -0800 (PST) Received: by mail-pf1-x433.google.com with SMTP id o9so1940878pfd.10 for ; Wed, 02 Dec 2020 12:13:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mtcc-com.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=R4Fc1Eybq3Tga7SsXo5PIDScEkn3zlnp3jAuzQ0GJiQ=; b=JU+GTAJSNF81FARGXk14F3dvnaPBMlqeTvTV2PGmKuEIEx9vx1y2Qs1r3DxQGuUZIG Bz3+jWW0K+I9y3GREzFIjH7LFbllf+AH8+j0wCTmS455dABN+UNpGN80d3RBx3o6FaTT kMkgtkk284yblkalj+GBawsnNe3Qx2YwL4NJIprsqZ4/vZvOpkgmrxlz72XpSCKIaRfI 53XSC42/FxcNGihsvcFso1x42SBP442613MsHfjyRYodkvzSskPWWiHxJSU74yo1us7Q hDXSKCu2mwIms8HP0GV8q/wwzV1MJ6s4EJ4kolwwtshrvJnuSjOt2zUr51nFljoqR92E 9xNA== 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=R4Fc1Eybq3Tga7SsXo5PIDScEkn3zlnp3jAuzQ0GJiQ=; b=pZzqVFB22+7ZXL3pxUCSLSBbPQh6aDJ6pXoU8BmgK7aSuoA0zfea9y/b5kOeLoJu4U N8P0Q3BMPs/0JDeMOcNSOkpjVy+s4NUd1eK6nKhtrS/WYMe+O12GDonp31tciGZnHONX e67e3bFNcf7LiCEhhvboTH/ghG0kwmPjem7wWeNbV6ORR/ANVYMBIRftUiaOqo1WXgYb PzyeQd2mSlBsFrN0G5R2a9D+3MEzQGzzTCpkjv1+e+FlDNPHORwBK638Gejesn5LzlF/ L36xA4tXN4K9F/1KbfM9Hkh+vWndXSGd58Ixb+tY2q+5mq7txnhbRfirQCSTRyGF5+Ib 4BYA== X-Gm-Message-State: AOAM530GmY6oTopLwazQmnTh9FYvn4Ep12RRptqwh9Qfw4C1/MLCf1E+ l/6CxzOE6MY7E70AFWtfVqQi3HtWFySjZQ== X-Google-Smtp-Source: ABdhPJwZ/Fn0NBOxQV6gv/WOL4qirotOs/cy0cLjO9Pu9bqSKBfECWOGxv9HImy7r4kQPsAnNOdVQA== X-Received: by 2002:a62:1942:0:b029:197:e232:cfd4 with SMTP id 63-20020a6219420000b0290197e232cfd4mr4142615pfz.53.1606940026946; Wed, 02 Dec 2020 12:13:46 -0800 (PST) Received: from mike-mac.lan (107-182-42-33.volcanocom.com. [107.182.42.33]) by smtp.gmail.com with ESMTPSA id l66sm519933pgl.24.2020.12.02.12.13.45 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 02 Dec 2020 12:13:46 -0800 (PST) To: Brandon Long Cc: John Levine , IETF DMARC WG References: <20201124020453.AFDC027CE5C8@ary.qy> <1eed8278-4efa-4abc-15e0-2efcf014e82e@mtcc.com> From: Michael Thomas Message-ID: <446d491b-100a-9813-6463-2294f67bbda7@mtcc.com> Date: Wed, 2 Dec 2020 12:13:44 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------BDD9B3FB7F2111D02A8AE5C8" Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] ARC questions X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 02 Dec 2020 20:13:51 -0000 This is a multi-part message in MIME format. --------------BDD9B3FB7F2111D02A8AE5C8 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 11/30/20 9:43 PM, Brandon Long wrote: > > To summarize what I said already in this thread, DKIM is taken by many > receivers as the responsible party for a message, in both spam and > phishing classifiers, with the latter being perhaps more relevant. > DMARC is the one example of that.  DKIM signing a message that > transits your system allows for reputation washing of the original > message.  The ARC chain is specified as a relay responsibility, which > is a lesser burden. > > Ignoring the existing usage of DKIM, DKIM+A-R would only work for a > single hop, and lead to some complication compared to the other DKIM > signatures already on the message. Wait, what? a DKIM signatures survives until it encounters an intermediary that alters the message in a breaking manner. Arc-Signatures are no different in that respect. In fact as far as I can tell they are identical modulo the i= difference. > > DKIM is not the only thing that can be reputation washed, SPF can as > well.  821.FROM rewriting is more common, so there are work-arounds.  > OTOH, SPF doesn't survive forwarding, but with ARC you can forward > it.  DKIM+A-R would only work for a single hop, and lead to some > complication compared to the other DKIM signatures already on the message. > So mtcc.com is now hosted by gsuite (::sigh::), > so you're saying that it would run into problems? I haven't put up > a DMARC policy, but if I did I might run into issues with false > positives? Like I said, I'm trying to get my head around what the > actual problems are, and this is coming from a person who stressed > mightily from the very beginning about the mailing list problem. > > It's unlikely you have a complicated mail flow involving multiple > vendors, but certainly there are plenty of configuration options > alllowing folks to shoot themselves in the foot. By definition a message hitting the front door of the destination domain (via an MX record) sees the DKIM signatures in the message and can process them at that point, or at some point before other manglers get a hold of the message. I don't see why we should care at all about what happens beyond the destination domain's front door because that's their problem not ours. The entire point of DKIM is the inter-domain case, not intra-domain. > > > With ARC, we can instead say "trust this arc admd" and have the data > passed directly, and also work around the DKIM breakage. But ARC suffers the same breakage with the ARC-Signature. And if the ARC-Signature is broken, you can't trust the sealed data because that's a trivial cut and paste attack as far as I can see. So I'm just not seeing how this is any better than just a plain old DKIM-Signature with the old auth-res renamed and signed since you can already for 15 years trust signing intermediaries or not. > > As for another comment in the thread about adding two signatures per > hop, there was a suggestion that it could be replaced with a single > signature per hop near last call with some loss of information > (maybe), but it was decided to move forward with the existing solution > that already had several implementations and was experimental anyways. > As I said elsewhere, since this is an active experiment and it's already been a year, it might be good to start documenting what the experiment is teaching us. I still after many messages have no clue what what ARC does that DKIM+old-auth-res cannot beyond tying the authres and signature together. It would be nice to know in a quantitative way why that is important, as well as any other things that cannot be done with DKIM+old-auth-res. In fact since I expect that most signature breaking intermediaries DKIM resign the messages (and if they don't thay aren't going to do ARC either), it would be very simple to chronicle how the two approaches differ in efficacy. The same reputation look for ARC can be done for DKIM too, after all. BTW: i can understand not wanting to touch DKIM or AUTH-RES proper for an experiment, but a standards track document should really consider just adding the binding tag to DKIM and Auth-res. They were both designed to be able to do that. Mike --------------BDD9B3FB7F2111D02A8AE5C8 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit


On 11/30/20 9:43 PM, Brandon Long wrote:

To summarize what I said already in this thread, DKIM is taken by many receivers as the responsible party for a message, in both spam and phishing classifiers, with the latter being perhaps more relevant.
DMARC is the one example of that.  DKIM signing a message that transits your system allows for reputation washing of the original message.  The ARC chain is specified as a relay responsibility, which is a lesser burden.

Ignoring the existing usage of DKIM, DKIM+A-R would only work for a single hop, and lead to some complication compared to the other DKIM signatures already on the message.

Wait, what? a DKIM signatures survives until it encounters an intermediary that alters the message in a breaking manner. Arc-Signatures are no different in that respect. In fact as far as I can tell they are identical modulo the i= difference.



DKIM is not the only thing that can be reputation washed, SPF can as well.  821.FROM rewriting is more common, so there are work-arounds.  OTOH, SPF doesn't survive forwarding, but with ARC you can forward it.  DKIM+A-R would only work for a single hop, and lead to some complication compared to the other DKIM signatures already on the message.

 

So mtcc.com is now hosted by gsuite (::sigh::), so you're saying that it would run into problems? I haven't put up a DMARC policy, but if I did I might run into issues with false positives? Like I said, I'm trying to get my head around what the actual problems are, and this is coming from a person who stressed mightily from the very beginning about the mailing list problem.

It's unlikely you have a complicated mail flow involving multiple vendors, but certainly there are plenty of configuration options alllowing folks to shoot themselves in the foot.

By definition a message hitting the front door of the destination domain (via an MX record) sees the DKIM signatures in the message and can process them at that point, or at some point before other manglers get a hold of the message. I don't see why we should care at all about what happens beyond the destination domain's front door because that's their problem not ours. The entire point of DKIM is the inter-domain case, not intra-domain.




With ARC, we can instead say "trust this arc admd" and have the data passed directly, and also work around the DKIM breakage.

But ARC suffers the same breakage with the ARC-Signature. And if the ARC-Signature is broken, you can't trust the sealed data because that's a trivial cut and paste attack as far as I can see. So I'm just not seeing how this is any better than just a plain old DKIM-Signature with the old auth-res renamed and signed since you can already for 15 years trust signing intermediaries or not.



As for another comment in the thread about adding two signatures per hop, there was a suggestion that it could be replaced with a single signature per hop near last call with some loss of information (maybe), but it was decided to move forward with the existing solution that already had several implementations and was experimental anyways.

As I said elsewhere, since this is an active experiment and it's already been a year, it might be good to start documenting what the experiment is teaching us. I still after many messages have no clue what what ARC does that DKIM+old-auth-res cannot beyond tying the authres and signature together. It would be nice to know in a quantitative way why that is important, as well as any other things that cannot be done with DKIM+old-auth-res.

In fact since I expect that most signature breaking intermediaries DKIM resign the messages (and if they don't thay aren't going to do ARC either), it would be very simple to chronicle how the two approaches differ in efficacy. The same reputation look for ARC can be done for DKIM too, after all.

BTW: i can understand not wanting to touch DKIM or AUTH-RES proper for an experiment, but a standards track document should really consider just adding the binding tag to DKIM and Auth-res. They were both designed to be able to do that.

Mike


--------------BDD9B3FB7F2111D02A8AE5C8-- From nobody Wed Dec 2 12:31: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 BCC163A1489 for ; Wed, 2 Dec 2020 12:31:23 -0800 (PST) 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 (2048-bit key) header.d=iecc.com header.b=cxZUpdbR; dkim=pass (2048-bit key) header.d=taugh.com header.b=FjeUFlv6 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SOgQzLZkFpUa for ; Wed, 2 Dec 2020 12:31:22 -0800 (PST) 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 D39AF3A1482 for ; Wed, 2 Dec 2020 12:31:21 -0800 (PST) Received: (qmail 25840 invoked from network); 2 Dec 2020 20:31:20 -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=64eb.5fc7f998.k2012; i=johnl-iecc.com@submit.iecc.com; bh=s+EG2a9vMSQy9urKL8MA14rlxETwvFxl4yx/DpFtMnE=; b=cxZUpdbRMAS27j+hk8sc/REtRKNvVDg7JvcqiLLgHhfQexoky6aFcYPPAljMJxJMpaExNpTjSP9faUEZXguwkK4SmOVjwuBT7NIlHKae6cq0QCU2fIoAW/ptNxpG149ynWfBjFiGUfCDnnRSx/al/7YaqYELZkTVn+fb2qNxIQT3yb66X2aW90JRpFKgltd/EqjfTQY9bybFG56FNhOmJxBi3Zy5FinQekqg7zWGouEMNEoLoL9+cStzh/IS6HroBiqKT4JNeRYtnO1STIc5KV0ly34dlBn6m018BpbPcbEVojhAUcUxTuX8JIsOJeNKlKHVtNJD/DmxbNTrV3J6OQ== 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=64eb.5fc7f998.k2012; olt=johnl-iecc.com@submit.iecc.com; bh=s+EG2a9vMSQy9urKL8MA14rlxETwvFxl4yx/DpFtMnE=; b=FjeUFlv6u8LvSbqMB5LIR/lTOu3k7gZ8dzKZgmgm838d7W/wP9OAzIJmxUzHOrp7kcfNIaq1e5jlEcn+lDHYvjWT41tOTK4o8u2q1DvlBf3g5jz1y36rnYezTjMNyqxXjZul5cUCHeaGhx1r56H57aBrTVyXQGgRiphwgJ2wq9T3MwBkUpJyrwo9g+t+u+gHoVPR/ihjPlFSKRaay4UM1x3ToLNfQdnUhjXhjkujGjgNRs6jW5yxmq2SJGLey/u/55KjADBDlgEccqrCeFsfvfLgwop0fCoYp3D7y3Ue0IA0sJb9fDzaaG6/719Mkon8boTFOZDjuqxbpmkIlBSiQg== 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; 02 Dec 2020 20:31:19 -0000 Date: 2 Dec 2020 15:31:19 -0500 Message-ID: From: "John R Levine" To: "Michael Thomas" , "Brandon Long" Cc: "IETF DMARC WG" In-Reply-To: <446d491b-100a-9813-6463-2294f67bbda7@mtcc.com> References: <20201124020453.AFDC027CE5C8@ary.qy> <1eed8278-4efa-4abc-15e0-2efcf014e82e@mtcc.com> <446d491b-100a-9813-6463-2294f67bbda7@mtcc.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII Archived-At: Subject: Re: [dmarc-ietf] ARC questions X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 02 Dec 2020 20:31:24 -0000 On Wed, 2 Dec 2020, Michael Thomas wrote: >> Ignoring the existing usage of DKIM, DKIM+A-R would only work for a single >> hop, and lead to some complication compared to the other DKIM signatures >> already on the message. > > Wait, what? a DKIM signatures survives until it encounters an intermediary > that alters the message in a breaking manner. Arc-Signatures are no different > in that respect. In fact as far as I can tell they are identical modulo the > i= difference. Please reread the ARC spec. The ARC-Authentication-Results at level N tells you whether the ARC and DKIM signatures were good at level N-1. R's, John From nobody Wed Dec 2 12:32: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 1C3CD3A1482 for ; Wed, 2 Dec 2020 12:32:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.652 X-Spam-Level: X-Spam-Status: No, score=-1.652 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mtcc-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eGouX-rOVhMz for ; Wed, 2 Dec 2020 12:32:38 -0800 (PST) Received: from mail-pg1-x530.google.com (mail-pg1-x530.google.com [IPv6:2607:f8b0:4864:20::530]) (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 EA48B3A1489 for ; Wed, 2 Dec 2020 12:32:37 -0800 (PST) Received: by mail-pg1-x530.google.com with SMTP id w4so1796021pgg.13 for ; Wed, 02 Dec 2020 12:32:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mtcc-com.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=g1w3J6YjXIddOa0ybF8yhkAbxTNmaSHBI6rRoWuyMns=; b=b7lNCBVOvjwaepZxX1CW28Sm8G1EMJZeIe5RLFftGYiI+i+04/5ZCd/3suPJcyxM1C FxkOTEzrk+ncFfCqbhBIxU9Mur9PpzmXoQP27O4ujtLASWvx7yMMcvAKLEmN6kF6EGtS Bxy3ZtGrAng6rey2WJrjZ+8d7D+dkQwnCcrkUHuxPCcJVZx53c0LrFADBDpdquYgFw3a Xs8xj5tycKLZQRdb/z7omSm4rK00Z1Arq/2Lxw58W+uCGgqkM5S+HEt1+E9Gr3HXRAso S2FAtNwkY2GPCjMbr6Af3X3mxKHTVaOsX7nbkcF6Laup/+rdl0mfdUNWnOgHjmi3rDKo HPdQ== 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=g1w3J6YjXIddOa0ybF8yhkAbxTNmaSHBI6rRoWuyMns=; b=UX4d8cWBSCPSJXbwq8/tWd0zYGdydDpbDmOxqOYQD215jQ8BPi8iXgLznnSAYt9782 F7+9Dr9H47p6iKpduNvtJ/Nx9oqHo7o83+1Q7tL6P1QHjxYlmgJg+rpeSt2IoFwNCDn5 7OWs3Yz/ZmMUNVd68iQwFa/V8Y0tbfUiHpwYjqDnRHQtChjrEIGV1ygAa0Ahphz/DLwe yH2LrZC83Kfd9JaLU4vMbaJpZahIVT6SucIu/4ef4zJc7ORd/TlsI0Oy/+EsPpGueYv+ Bd70CNdIMP9y8e66v9bmHxPSRDHHi7W2xpyaVWcgXEl3nnBZ/ZEM8+3K8OfBFz6nBis5 W/4w== X-Gm-Message-State: AOAM5329dICtklAMbIhPTrYmFznbjLr/1Ef9T2lyPyGi9IfdYJAsRnmT Ez2ZiywzLUBFNK/csabnEtD01Ar6CgRuYQ== X-Google-Smtp-Source: ABdhPJzLCI5ahn4wCPcL13hZ4NPypat3giBPKmcRNRXw6yF1sRz4EqN9ejeoicPan9WU9cwKCnnHBQ== X-Received: by 2002:a62:1c88:0:b029:197:f6e4:bc2b with SMTP id c130-20020a621c880000b0290197f6e4bc2bmr4544529pfc.6.1606941156869; Wed, 02 Dec 2020 12:32:36 -0800 (PST) Received: from mike-mac.lan (107-182-42-33.volcanocom.com. [107.182.42.33]) by smtp.gmail.com with ESMTPSA id d19sm446004pjs.0.2020.12.02.12.32.35 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 02 Dec 2020 12:32:36 -0800 (PST) To: John R Levine , Brandon Long Cc: IETF DMARC WG References: <20201124020453.AFDC027CE5C8@ary.qy> <1eed8278-4efa-4abc-15e0-2efcf014e82e@mtcc.com> <446d491b-100a-9813-6463-2294f67bbda7@mtcc.com> From: Michael Thomas Message-ID: <4190de2d-9f17-06d5-6354-30c989eecd4a@mtcc.com> Date: Wed, 2 Dec 2020 12:32:34 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.5.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] ARC questions X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 02 Dec 2020 20:32:39 -0000 On 12/2/20 12:31 PM, John R Levine wrote: > On Wed, 2 Dec 2020, Michael Thomas wrote: >>> Ignoring the existing usage of DKIM, DKIM+A-R would only work for a >>> single hop, and lead to some complication compared to the other DKIM >>> signatures already on the message. >> >> Wait, what? a DKIM signatures survives until it encounters an >> intermediary that alters the message in a breaking manner. >> Arc-Signatures are no different in that respect. In fact as far as I >> can tell they are identical modulo the i= difference. > > Please reread the ARC spec.  The ARC-Authentication-Results at level N > tells you whether the ARC and DKIM signatures were good at level N-1. > That's why I said "modulo the i= difference" Mike From nobody Wed Dec 2 12:35:12 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B4533A1491 for ; Wed, 2 Dec 2020 12:35:10 -0800 (PST) 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 (2048-bit key) header.d=iecc.com header.b=FyjJylNP; dkim=pass (2048-bit key) header.d=taugh.com header.b=YFRFpzoT Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sAHkXmyILJYD for ; Wed, 2 Dec 2020 12:35:08 -0800 (PST) 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 1F5913A148B for ; Wed, 2 Dec 2020 12:35:08 -0800 (PST) Received: (qmail 27331 invoked from network); 2 Dec 2020 20:35: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:references:mime-version:content-type; s=6ac1.5fc7fa7b.k2012; i=johnl-iecc.com@submit.iecc.com; bh=trRLRstrRuZ+SELhHGkyLKq1TK1qZJdOVuMPIAUIui8=; b=FyjJylNPw8U3/Zcq95kAfQJCYjUa1B7dQyNy+1SKgMC61qFy4F2n57tLyNBud39uCuB2O3LlfRYtAS7py20JomOMgDhG0MbhEP3RaGVBxfA4vs6KbxPkicLB8gVtXjbUaxOYmGAEW21d2N9VpHmclm/tNEhopAacBSH9RZkUk0Tx7Itst7wIRNRJjf4V+IppyO+DNu6WDMpnevGoglVsxfmBdjBld8DlcGr34PfAaCKs2v0wlJtnG05u/4acaS7jpo4SdREJKoszUW93cptbToeaspy28MyHiypLW94uDDmfp3dXiBZNGAf+pe/2P8WUrsME2DqtlIFPYnWb99xpAA== 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=6ac1.5fc7fa7b.k2012; olt=johnl-iecc.com@submit.iecc.com; bh=trRLRstrRuZ+SELhHGkyLKq1TK1qZJdOVuMPIAUIui8=; b=YFRFpzoTGktwjtcmIrvSlvLLJPsL9W3m/y3m3zCQuT78QaGLSneOohG7iSCraoVCjFacvq7ePotX32W2dgNrcdZYhY8f0Z0bv1GXUon21pfxmD+YlaV2xC/nJ2/NqWCLTQ1ugTnOrd03nEHKortwG/BAvuWqjMPMQPzrxeCjqqokj1CTzzXCftGH27YAfPfXneTdjYEkUWQoSkqqInfsVUbyrrArfew0agwPab8L67HvVXfkr9+oCwKJ5m1Z5cQmg4SfFikMPvkOfrwCirPmyCiexijDuPj9PMvAoROERxOAxwQeVm0h4+b9XSI1upfmq9DllL9I1bCuwC7yDXSqQg== 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; 02 Dec 2020 20:35:06 -0000 Date: 2 Dec 2020 15:35:06 -0500 Message-ID: <17d886fd-49fd-28d8-f8e4-7caf2e85919c@taugh.com> From: "John R Levine" To: "Michael Thomas" , "Brandon Long" Cc: "IETF DMARC WG" In-Reply-To: <4190de2d-9f17-06d5-6354-30c989eecd4a@mtcc.com> References: <20201124020453.AFDC027CE5C8@ary.qy> <1eed8278-4efa-4abc-15e0-2efcf014e82e@mtcc.com> <446d491b-100a-9813-6463-2294f67bbda7@mtcc.com> <4190de2d-9f17-06d5-6354-30c989eecd4a@mtcc.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="0-1578719195-1606941306=:10647" Archived-At: Subject: Re: [dmarc-ietf] ARC questions X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 02 Dec 2020 20:35:10 -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-1578719195-1606941306=:10647 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT On Wed, 2 Dec 2020, Michael Thomas wrote: >>> different in that respect. In fact as far as I can tell they are identical >>> modulo the i= difference. >> >> Please reread the ARC spec.  The ARC-Authentication-Results at level N >> tells you whether the ARC and DKIM signatures were good at level N-1. > That's why I said "modulo the i= difference" Well, yeah. That i= is why we have ARC seals rather than just using a DKIM signature. Remember that ARC is only useful if the last system sending the message to you is reasonably trustworthy, not in the sense that it never sends spam, but in the sense that its ARC tells the truth about what it saw. That's a low bar that any mailing list should be able to meet. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly --0-1578719195-1606941306=:10647-- From nobody Wed Dec 2 12:38: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 EDBFB3A15C2 for ; Wed, 2 Dec 2020 12:38:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.652 X-Spam-Level: X-Spam-Status: No, score=-1.652 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mtcc-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 93CQzIaiGr05 for ; Wed, 2 Dec 2020 12:38:36 -0800 (PST) Received: from mail-pl1-x636.google.com (mail-pl1-x636.google.com [IPv6:2607:f8b0:4864:20::636]) (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 4D0193A15A0 for ; Wed, 2 Dec 2020 12:38:35 -0800 (PST) Received: by mail-pl1-x636.google.com with SMTP id l11so1800696plt.1 for ; Wed, 02 Dec 2020 12:38:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mtcc-com.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=J5SPn7dDi8uA8BRZxZEJ6OVzRE5qHHFvL/CjPS2urFg=; b=BhoT3U2f+WpyvIxVgja5ec4WJwynKIki05FPZ2nNIhupvJadgp2xz4jL9RKqr/afGJ HoCR5rsoGREI+thgZmjM/TEmeTN00ZIONqVkMu4uQfaFhckQTy3ZbqsrGwLCTZgpQgIR rQWCYjXxl1gmusJLZMcXc5CtR4PFFtkpiSaExK3aVm7PmWkfm6HocxjDfB5Lg4LxqyvQ btRhWuWZowN/dtsWiBSXlgjBxasV9UPAMaAXuhitnLaNOFuK3OVtUrJyLiCC6/ojl8s+ R7GL7L4IVjdGWJiUVKwQfLij19XK78v1wdSMH5uuS6Pub/BR98d9hNrOscKObrTSWu7P DS/A== 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=J5SPn7dDi8uA8BRZxZEJ6OVzRE5qHHFvL/CjPS2urFg=; b=WJ3VLk30UpaImlTinlBmJ6A7ZB+6uLHw9Nu4dQb/LK8L5dDAYDJEilRtQNpejK05ij 7ZnKI0R1H0juZ2xs8NuYY/LTqd6/VIHCKiZIA2AYq5nis0GOv+5NS4gxS55u2ZZSmGOL 0Vd3X0VTSWfR8fxsOCeqou4RYlnE+owKIR5v5V2x0y1N8kob6llfokrxR0NEEoh8OJpc ylBlvQy4HYyGeDXGmfAkBEe7MRm32NvmDcyoY1iuLezPQEcAltufgXZ0D0TVnKEJsQ+1 6ePCYg06eaHxdM0DAKwBLSyPJ68uqU0IstPjk8Az0h/W/aFfBnCi6jDyL9T2naZMOJCv 8DOA== X-Gm-Message-State: AOAM531+VLzVm6wikau22XkA62PxqpsJ7IQTqZiQh8lNVJDZeI01f1bP rMpHE8og53OGmGfXIvcA+JJaRVO4U0cg3A== X-Google-Smtp-Source: ABdhPJyCPYKdqiYahxmrJi6YA57MFGmUxw34twLJzhE+HV277rzrh2ptsA5vPy3kFZPJ09cEFdWUFg== X-Received: by 2002:a17:902:6acc:b029:d8:c6ee:6d6c with SMTP id i12-20020a1709026accb02900d8c6ee6d6cmr4202105plt.7.1606941514496; Wed, 02 Dec 2020 12:38:34 -0800 (PST) Received: from mike-mac.lan (107-182-42-33.volcanocom.com. [107.182.42.33]) by smtp.gmail.com with ESMTPSA id x16sm430479pjh.39.2020.12.02.12.38.33 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 02 Dec 2020 12:38:33 -0800 (PST) To: John R Levine , Brandon Long Cc: IETF DMARC WG References: <20201124020453.AFDC027CE5C8@ary.qy> <1eed8278-4efa-4abc-15e0-2efcf014e82e@mtcc.com> <446d491b-100a-9813-6463-2294f67bbda7@mtcc.com> <4190de2d-9f17-06d5-6354-30c989eecd4a@mtcc.com> <17d886fd-49fd-28d8-f8e4-7caf2e85919c@taugh.com> From: Michael Thomas Message-ID: Date: Wed, 2 Dec 2020 12:38:31 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 MIME-Version: 1.0 In-Reply-To: <17d886fd-49fd-28d8-f8e4-7caf2e85919c@taugh.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] ARC questions X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 02 Dec 2020 20:38:45 -0000 On 12/2/20 12:35 PM, John R Levine wrote: > On Wed, 2 Dec 2020, Michael Thomas wrote: >>>> different in that respect. In fact as far as I can tell they are >>>> identical modulo the i= difference. >>> >>> Please reread the ARC spec.  The ARC-Authentication-Results at level >>> N tells you whether the ARC and DKIM signatures were good at level N-1. > >> That's why I said "modulo the i= difference" > > Well, yeah.  That i= is why we have ARC seals rather than just using a > DKIM signature. > > Remember that ARC is only useful if the last system sending the > message to you is reasonably trustworthy, not in the sense that it > never sends spam, but in the sense that its ARC tells the truth about > what it saw.  That's a low bar that any mailing list should be able to > meet. > Which could trivially be added as an extension to DKIM and Auth-Res negating the need for the Seal altogether since DKIM can directly sign the old (renamed) auth-res. I can understand for an experiment not wanting to touch dkim or auth-res, but for something standards track less is more. Mike From nobody Wed Dec 2 14:35: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 4853D3A14F5 for ; Wed, 2 Dec 2020 14:35:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.651 X-Spam-Level: X-Spam-Status: No, score=-1.651 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_HELO_NONE=0.001, SPF_PASS=-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 HqpTGfWk3wak for ; Wed, 2 Dec 2020 14:35:43 -0800 (PST) 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 9E5293A14D8 for ; Wed, 2 Dec 2020 14:35:43 -0800 (PST) Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1kkair-00068i-90 for dmarc@ietf.org; Wed, 02 Dec 2020 23:35:41 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: dmarc@ietf.org From: Benny Lyne Amorsen Date: Wed, 02 Dec 2020 23:35:35 +0100 Message-ID: <87r1o7alag.fsf@orion.amorsen.dk> References: <20201202021651.E8EE128C576A@ary.qy> <327860af-2fa7-63ee-4b89-6e7e383f3d53@crash.com> <2804da89-84d1-f601-9425-0b0d9baf6ae1@gmail.com> <1f6cae74-4eed-47f5-7249-e526bf1f5845@crash.com> <87y2ig9t9i.fsf@orion.amorsen.dk> Mime-Version: 1.0 Content-Type: text/plain User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) Cancel-Lock: sha1:zQDqHzILijyXLplnpOEdhffq5hI= Archived-At: Subject: Re: [dmarc-ietf] Ticket #39 - remove p=quarantine X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 02 Dec 2020 22:35:45 -0000 Dotzero writes: > p= DID NOT mistakenly choose to use the language of receiver > actions. p= represents the domain-owner request to the receiver as to > the disposition of messages which fail to validate. Any reading of > "concern" is supposition on the part of yourself or other self > appointed interpreters of the mind of the domain-owner or > administrator. [..] This is an interoperability standard, not a > seance. Am I particularly thin-skinned for considering this language inflammatory? The thing is, domain owners can request anything they want, but why should anyone listen? Particularly if they are rude about it instead of asking nicely. When someone brings up a concern they have and explain why it is of benefit to either the recipient or the community to take certain actions, that will likely be heard. However, unexplained edicts are unlikely to be taken very seriously. From nobody Wed Dec 2 14: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 324983A15BC for ; Wed, 2 Dec 2020 14:53:37 -0800 (PST) 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 (2048-bit key) header.d=iecc.com header.b=GoB+9AKe; dkim=pass (2048-bit key) header.d=taugh.com header.b=Ute0SUcS Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rSZW44Lq5Gai for ; Wed, 2 Dec 2020 14:53:35 -0800 (PST) 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 ED0AB3A15BB for ; Wed, 2 Dec 2020 14:53:34 -0800 (PST) Received: (qmail 62066 invoked from network); 2 Dec 2020 22:53:33 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type; s=f270.5fc81aed.k2012; i=johnl-iecc.com@submit.iecc.com; bh=NdzM4uGljegr9S3lLRprnHmJ1FiaDF5xJK6vzxddXt0=; b=GoB+9AKe+MqDeqnEQyC9x3TLhPgAlm5n82gKDLRlRgtHpqsCsYCWv0T0Sr7gkdxdgtu4bE5kTpXCslp7Mqg9VFn885N4hjgzv/Kx6s3T+mKbNfUlu5LxqOw31IrSuG3lxZPshWeT+QO5FvJJyIg+w3kt5ZcAJsO/LiAu3tuaQiwWPA2cS5X8y46WPe0XEqHok91jiTcoY1pmXvz64KzqwVzDMDMscfkcCnsZ9IsyDlq545YTvEDAAMn4nUP6zfFHoZ0IgdMlisf9Z3nZrOknXqkIvGPFk5y6yAr/2JZt8V7lQqh+3Wf/4Dorv3+lUJL7i/VltHHK1bI+9zhAzEp2BA== 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=f270.5fc81aed.k2012; olt=johnl-iecc.com@submit.iecc.com; bh=NdzM4uGljegr9S3lLRprnHmJ1FiaDF5xJK6vzxddXt0=; b=Ute0SUcS4fZXrCjUTv3GPy3H7EWrp3uOGU080XkjaZFJ1zGNreyGm/g3QA8VDVu4QZmqJ9NBeBOOkcAV8JZR2nIlZXogqVlL1hKbNA9ZuAs1vjTDzWCV89Tac+C/Cw4io4zqqU9mIGTQynDAc4Z5gKjNAGx6mL1LhuWyvOlAd1TgdnYP3lXbJe63d+b0LBoqesPjjjZ5mgYG5pn93KmqynoWfxthYm3VN9XH4DA25a8V4ruzEhcTDUm4IPItQQovWXrOAnfz6G+OOJXah/QR+P6PUZA7dDRHzqeFmGFFwvaZKquLRCyhDiYHOUwWcIKFE6wWS22ZUr5e0mJdvWUaQg== 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; 02 Dec 2020 22:53:33 -0000 Date: 2 Dec 2020 17:53:33 -0500 Message-ID: From: "John R Levine" To: "Michael Thomas" , "Brandon Long" Cc: "IETF DMARC WG" In-Reply-To: References: <20201124020453.AFDC027CE5C8@ary.qy> <1eed8278-4efa-4abc-15e0-2efcf014e82e@mtcc.com> <446d491b-100a-9813-6463-2294f67bbda7@mtcc.com> <4190de2d-9f17-06d5-6354-30c989eecd4a@mtcc.com> <17d886fd-49fd-28d8-f8e4-7caf2e85919c@taugh.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [dmarc-ietf] ARC questions X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 02 Dec 2020 22:53:37 -0000 > Which could trivially be added as an extension to DKIM and Auth-Res negating > the need for the Seal altogether since DKIM can directly sign the old > (renamed) auth-res. I can understand for an experiment not wanting to touch > dkim or auth-res, but for something standards track less is more. I still don't get it. I suppose the ARC group could have done something to register extra tags for DKIM-Signature and A-R and tried to do something about the fact that if a message passes through the same network twice, the first A-R will be deleted, and try and find and turn off all of the places where mailing lists helpfully delete DKIM signatures that no longer are valid, and what they came up with wouldn't work a whole lot worse than ARC does. But why bother? The IANA header field registry currently has 419 entries. Why is it a crisis if it increases to 422 rather than 420? Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From nobody Wed Dec 2 15:30:12 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 941053A15FA for ; Wed, 2 Dec 2020 15:30:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.652 X-Spam-Level: X-Spam-Status: No, score=-1.652 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mtcc-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dovppe2unYSd for ; Wed, 2 Dec 2020 15:30:09 -0800 (PST) Received: from mail-pj1-x1031.google.com (mail-pj1-x1031.google.com [IPv6:2607:f8b0:4864:20::1031]) (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 D92243A15FC for ; Wed, 2 Dec 2020 15:30:05 -0800 (PST) Received: by mail-pj1-x1031.google.com with SMTP id e5so57021pjt.0 for ; Wed, 02 Dec 2020 15:30:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mtcc-com.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=frJndGBg4PljdPRXFB1KqYuhqqDFqbuyeJjhznmBtNo=; b=vvoZ+Loew2ueICysZfzHi5UwJ3jXLN5dX+kyHN3HI91ZMJWMq7cym6dw1XQ9zaHvar KWobHhYgPlIURrzw5+sM1lArZM0+S8zElTI9oJicfts5VpsuYtc3kGzpFO58DlGQMzji +Bshah0JzXltImvCLjzUhHXHOLYvfA/Hk9lwY5XD904cTcBo4UfTKvenfFv3yLyBc4k3 l61UDIWK7HRcdixAnDYx7zJLZaO3qcbPOwkG48uqCoMDIJVhcBndL82W/JflTPy4EB9S VydV+ABOODKddInyT2i5+/cTXS1B66NWYHF/Auh1UqRkxB/+H5T//oXYkKWqXolceqkS Y3Nw== 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=frJndGBg4PljdPRXFB1KqYuhqqDFqbuyeJjhznmBtNo=; b=VGzj3IYpDnfKOxHHOBvlPC5Rl2UZRiU+pFuWtw1YQhxeAzvTsBzqEtETwQfKa01Twt 18oW5glz5BM5SXq4v1bkFStlyppI9zH8iKhiu0CD7aBAQys59Lnc9mz0T64qymNuRJ2a KslbZywMkCLT4Yo9LwZZHsl27as+8d9bCe4GPbMt7EMFqs6/Eu5vfR0umlfg+eygg81h qnYw/YMNPdnUPo0AmU31RMjuBK/7t7C/GTYpP52YfI97EPTIovNvjmRMJAqxiefyYnmb 97ThJaIe6eFDAHhPUBo4ZG87o61csFEtu/Ex9pvRN0J9KRfRGKWSVOjdM1jE8lOV9OKt eVbQ== X-Gm-Message-State: AOAM530dUJVHp8wabcixnDGLPCjPeoZKT08gK6Tus4aFML8E1Rwj4sLT n/1T4bYrbhLK6wQWt/9nu1rg0LKqSFCEuQ== X-Google-Smtp-Source: ABdhPJzQUtiWyUp4dVxdii6hT+h4YBukyVaoJ5846n5Di6IUaEwxKrufF/3Atxm7lejww+dr4k5xIw== X-Received: by 2002:a17:90a:c4f:: with SMTP id u15mr287214pje.177.1606951804840; Wed, 02 Dec 2020 15:30:04 -0800 (PST) Received: from mike-mac.lan (107-182-42-33.volcanocom.com. [107.182.42.33]) by smtp.gmail.com with ESMTPSA id x7sm158495pfn.85.2020.12.02.15.30.03 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 02 Dec 2020 15:30:04 -0800 (PST) To: John R Levine , Brandon Long Cc: IETF DMARC WG References: <20201124020453.AFDC027CE5C8@ary.qy> <1eed8278-4efa-4abc-15e0-2efcf014e82e@mtcc.com> <446d491b-100a-9813-6463-2294f67bbda7@mtcc.com> <4190de2d-9f17-06d5-6354-30c989eecd4a@mtcc.com> <17d886fd-49fd-28d8-f8e4-7caf2e85919c@taugh.com> From: Michael Thomas Message-ID: <8bc3c7ad-2a42-3eed-524c-8c50b16131c2@mtcc.com> Date: Wed, 2 Dec 2020 15:30:01 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.5.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] ARC questions X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 02 Dec 2020 23:30:11 -0000 On 12/2/20 2:53 PM, John R Levine wrote: >> Which could trivially be added as an extension to DKIM and Auth-Res >> negating the need for the Seal altogether since DKIM can directly >> sign the old (renamed) auth-res. I can understand for an experiment >> not wanting to touch dkim or auth-res, but for something standards >> track less is more. > > I still don't get it.  I suppose the ARC group could have done > something to register extra tags for DKIM-Signature and A-R and tried > to do something about the fact that if a message passes through the > same network twice, the first A-R will be deleted, and try and find > and turn off all of the places where mailing lists helpfully delete > DKIM signatures that no longer are valid, and what they came up with > wouldn't work a whole lot worse than ARC does. > > But why bother?  The IANA header field registry currently has 419 > entries. Why is it a crisis if it increases to 422 rather than 420? > It does a lot more than that: 1) It adds two new signatures to an already existing DKIM signature that mailing lists add 2) It adds a new security mechanism (Seal) and adds a new attack surface, when the old (renamed) auth-res could just be DKIM-signed which has been thoroughly vetted 3) It adds a lot more bloat to the headers 4) Signing is a *far* more expensive operation than verifying, and you negated any supposed advantage by adding two new signatures to verify for lists that unhelpfully strip the original signature I see a lot of anecdotes and speculation going on here and very little hard data. This has been going on for at least a year. Since this is an experiment, that is very worrying. More worrying is that I can't get a straight answer on what exactly the value is of the mailing list's auth-res is to filtering decisions. That seems to be the lynchpin to all of this, but from what I'm seeing it's like an article of faith. Mike From nobody Wed Dec 2 15:34: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 795C13A1601 for ; Wed, 2 Dec 2020 15:34:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.851 X-Spam-Level: X-Spam-Status: No, score=-1.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iecc.com header.b=KBzY7MA5; dkim=pass (2048-bit key) header.d=taugh.com header.b=YP3CpJzG Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IHZb-8MskpCS for ; Wed, 2 Dec 2020 15:34:35 -0800 (PST) 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 8A8813A1600 for ; Wed, 2 Dec 2020 15:34:35 -0800 (PST) Received: (qmail 71661 invoked from network); 2 Dec 2020 23:34:33 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=117e8.5fc82489.k2012; bh=//A8FUy2MU9YqMp+GWUFQmYK8NbEK34W38Nsczhriw8=; b=KBzY7MA5OyQUsq4rYxei4qvuZbUbfGKhYufn1r1W2RsAlylt2zY6nngUTVkEf7eR8t44JU34wKceKqPlYeIZNg6lhf/lJ8RRGfjjqKyzAFUmjgytHYYtwIxoMn3qE7UKLYYzcZTrevUAi2VwOSOyRcPSm/G2o54YzQvKyQjZ5kSZsqxW/clSjIRcWsC+vYsHqf0goCVm4Ta65og6+lbUwv8juP1FMYAN8PT3FRHztI6M9/sajZpkyf4fssViY1PrfZ8mzeDO9S7tiyiCoxIVOMym55pYylXTbXhs69lLs7p1WT4cwk15GJ3K/mNL2GMJx99HJ/kPLeiKL/+LMK1Ohg== DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=117e8.5fc82489.k2012; bh=//A8FUy2MU9YqMp+GWUFQmYK8NbEK34W38Nsczhriw8=; b=YP3CpJzGfvwxVXoadvaiKzor14i9/sjEu5RyTfm2sKusU22JePv6ReiWCC1n7CDJLreKIZD0V0cvtSuMMwt/vg6q8Uyp8fqqruU+jzSQKdEFIXb4XA/vomGv/oWRolW4AqoYWhZvZ+X7f9cJfJhQhlaD0Pt8nvMsTS/4x4E3W/hfPCGjCyGCDo58mZKP9sdaQ7MBoIq/G3Lnyv6BIle8w6/rX+7MSl0VCI9VngvEddLUcvMeUpHBEJ3da7twdpW1psPnDNJ/izfnpI97zT/jkm7bdO6J16a84IJ6bcHRcXPE86pDPHVQ1khpWvU+jAmpHh7PWc1tWXNwtseMBqX90Q== 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; 02 Dec 2020 23:34:33 -0000 Received: by ary.qy (Postfix, from userid 501) id D45FB28E1943; Wed, 2 Dec 2020 18:34:32 -0500 (EST) Date: 2 Dec 2020 18:34:32 -0500 Message-Id: <20201202233432.D45FB28E1943@ary.qy> From: "John Levine" To: dmarc@ietf.org Cc: vesely@tana.it In-Reply-To: Organization: Taughannock Networks X-Headerized: yes Cleverness: minimal Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] Ticket #42 - Expand DMARC reporting URI functionality X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 02 Dec 2020 23:34:38 -0000 In article you write: >On Tue 01/Dec/2020 23:21:48 +0100 John R Levine wrote: >> We can adapt the approach MTA-STS uses in RFC 8460. >> >> If rua= has an https URI, the reporter uses HTTP POST to that URI with >> the report as an uncompressed or gzipped XML file as the POST body. > >TL;DR: neutral > >Delivery via https, with possible retry queue, imposes an additional burden to >report producers. Since there seem to be less producers than consumers, it may >be fair to grant the choice of transport to the former. That is, to make the >mailto scheme mandatory and https optional. > >Even if the the spec allows consumers to specify the transport they like >better, there will probably be producers which only honor one type. So, >consumers may want to specify both schemes anyway. That seems reasonable to make mailto: mandatory and https: optional if you have an rua tag. I wouldn't expect reporters to provide queueing if https fails, and mailto is certainly not going away. But if both are available, http is a lot faster. >A better means to control report size is to gauge the reporting interval. When this came up before someone said that reports can be extremely large, many megabytes. An HTTP POST or PUT is a much better way to send that. Here's another nit: POST doesn't pass the report's filename. There should be a copy of the name in the header of the gzip data, but semantically it would be better to do an https PUT to /. That also has the advantage of being idempotent so if it puts the same file twice the server can tell it's a duplicate. R's, John From nobody Wed Dec 2 15:53: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 C42263A161B for ; Wed, 2 Dec 2020 15:53:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.651 X-Spam-Level: X-Spam-Status: No, score=-1.651 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mtcc-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lLPh_3Gr2eUe for ; Wed, 2 Dec 2020 15:53:27 -0800 (PST) Received: from mail-pg1-x534.google.com (mail-pg1-x534.google.com [IPv6:2607:f8b0:4864:20::534]) (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 AC5A13A1619 for ; Wed, 2 Dec 2020 15:53:27 -0800 (PST) Received: by mail-pg1-x534.google.com with SMTP id m9so273107pgb.4 for ; Wed, 02 Dec 2020 15:53:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mtcc-com.20150623.gappssmtp.com; s=20150623; h=to:from:subject:message-id:date:user-agent:mime-version :content-transfer-encoding:content-language; bh=h5M2HNGRxsgb86APR4KEZKwhX5h33ECRLU4YqyNft94=; b=E2fYrTA4XDREUqOaE4wse6RSduAwvV8sNhxC1LQOk29/z7KVxZsJIcYm4fQLc7szoY 1c49gUbXGaBn3kmrDTNamkZnzslfQ47VvIh1xGP93W9J6oJ2UoPGGDFiRG3RMWU/rKfW 4w4hWdoc0Z+sEeUqzNL9/Q0opqgiybgiW03osmXfTJelYr8dgOGOk11YpnNs+jF5wYvE 6V0csBDD3qGdYboZRXHI8FZEc/zKdDqdd6vO6U2LmwKaIFyLdRbeyBIEvjGd27pDLSM+ GCC8dCuzLz1Secbtdis2W8TEEYqyV3zqau6Ulk+jpeyeim1GozeSWUMGOTiwKwqUzKQY ydnA== 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-transfer-encoding:content-language; bh=h5M2HNGRxsgb86APR4KEZKwhX5h33ECRLU4YqyNft94=; b=EExqYhhX1HTqLW7+tAAepows8Y6vgqcgbXTN6gypVhIfqPa2Hck3XEMGmgWsVoSzWk Q3HsuzM+rfTuHghlD+plMIGa/c+1fPkdGwLIjlyB+8O0Px3Mpy7N14O4nTBjrOuDtDb8 BpNWvvV2cuFO0R5B/NkYWpXoVej3DaPbS9oGKrIvi3Up3W2bqlUPJBkj/rwl7Jdxysgy +dPBElogfHHtHH5UkBtuZeupVxSIEY/8+2NKttT8JrWtDIdAqlLZ3qwSvOM20m+98sOT p7NS1y4Nrnw1xM1f3khyEO3Tt75MPgvmg23SpyXwsxCzx/iPBZsxXX8ZHabvNHZFQWYO labg== X-Gm-Message-State: AOAM533jTcs9iFYiO0MRfqUOVP3bPQDMVB3OM2noFBewna6s1aicgSft XQYCiv86mJNP1VeSHYLvc9oK6nKvzJ+tvg== X-Google-Smtp-Source: ABdhPJzeXAAuwBJ+TaF10Z93B+chzhjuomKaUrxGHNQQjfgSaBxr4ucUNNEm3q0ByfreWQKOctBp2Q== X-Received: by 2002:a05:6a00:9d:b029:18c:8dac:4a96 with SMTP id c29-20020a056a00009db029018c8dac4a96mr580499pfj.22.1606953206581; Wed, 02 Dec 2020 15:53:26 -0800 (PST) Received: from mike-mac.lan (107-182-42-33.volcanocom.com. [107.182.42.33]) by smtp.gmail.com with ESMTPSA id p15sm47231pjg.21.2020.12.02.15.53.25 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 02 Dec 2020 15:53:25 -0800 (PST) To: "dmarc@ietf.org" From: Michael Thomas Message-ID: <38016bbf-b630-d4e9-532c-a7370412f707@mtcc.com> Date: Wed, 2 Dec 2020 15:53:24 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: [dmarc-ietf] Advancing ARC? X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 02 Dec 2020 23:53:29 -0000 Was/is there a plan to advance ARC to standards track? I see in the rfc that there are some questions that assumedly need to be answered. I would hope that that list is not exhaustive and that other questions can be posed to determine whether to go forward. As I've said in the other thread, it's been extremely hard to tease out what problem is actually being solved, and especially whether that problem is worth being solved in the first place. It seems to be that the Auth-Res from the intermediate mangler has some value, but I have been unsuccessful finding out why it is valuable. That leads me to think two things are probably needed: 1) A problem statement/requirements which details why the mechanism is valuable and why it can't be done with existing technology 2) An informational report whether the experiment had value and especially hard numbers rather than anecdotes. As in why should I trust ARC to turn my policy to "reject" and not suffer consequences? Mike From nobody Wed Dec 2 18:34: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 56D133A0977 for ; Wed, 2 Dec 2020 18:33:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.5 X-Spam-Level: X-Spam-Status: No, score=-1.5 tagged_above=-999 required=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, URI_HEX=0.1, URI_NOVOWEL=0.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iecc.com header.b=N+MoZgoF; dkim=pass (2048-bit key) header.d=taugh.com header.b=X5CvIpjc Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tIM9fxzPN-Cs for ; Wed, 2 Dec 2020 18:33:55 -0800 (PST) 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 0562E3A09D1 for ; Wed, 2 Dec 2020 18:33:54 -0800 (PST) Received: (qmail 22408 invoked from network); 3 Dec 2020 02:33: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:references:mime-version:content-type:content-id:original-authentication-results; s=5785.5fc84e90.k2012; i=johnl-iecc.com@submit.iecc.com; bh=Vnj1VfpxXINtZNewSiw2As/oYfokM6Q2RsROFmGHpAs=; b=N+MoZgoFSh2IQFnaS+qIGsCjIcRfonnble8qUw9t6T+eiji+e7sBIGnRsbOzxwYwr7dM3YB1gMA9QibrR5e9lBRzbavcJawXPqe1XlJAOF+zvisWjoFPUARAPIFgPsPREXLPE6YoKE/xxOLrLhuvuQaAuK9YOifG+pqSmVdfrwVNGNs9nZdvjhvpxec+wIrWDSdmCBBR6W3T6qCs/x9iMQY6Y+Ks5mSkqma5RdddP8t2wHrf2tfESsVE2h9l7vovBTUZ6b7ooDGWyqyROsLPVWzoGlo021IEaALk533P+28a+adV+uTB4VLALQK9crFJgfGlqQanAG1iSbb0BrtkbQ== 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:content-id:original-authentication-results; s=5785.5fc84e90.k2012; olt=johnl-iecc.com@submit.iecc.com; bh=Vnj1VfpxXINtZNewSiw2As/oYfokM6Q2RsROFmGHpAs=; b=X5CvIpjcG0+aLOgK5staM+aePkoWp+SehVaXOK6Hrq0PZiKTrIcnkfYl12+e/JLjn8pqawdcjUDbygfdUlS27QwoIh0tp07kv+4TFAtbRSG6hLm2EAIQl61RPLe4jctQHzuvhD/ml6pd6QnTsJ5coQ/oSJ2yAYWSn8NsgMyfZCXRX6FJTqgXskEPZGLQugAoBY/OsDUK/Dchz+Rf7NE8GeY27ztindLkJFa919oNb9zBVwl5JVQ1NRanxPspj8uyUDPWXDLgNeSUKIldTMNb+8eGwf73LxSjiXMJ+YHoLrZBG9O38q4NPk5wvIh07pEewhWXU5YFLRFI8xyyIuELEQ== Original-Authentication-Results: iecc.com; spf=pass spf.mailfrom=mike@fresheez.com spf.helo=mail-pl1-x62a.google.com smtp.remote-ip="2607:f8b0:4864:20::62a"; dkim=pass header.d=mtcc-com.20150623.gappssmtp.com header.s=20150623 header.a=rsa-sha256 header.b="vvoZ+Loe" 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; 03 Dec 2020 02:33:52 -0000 Date: 2 Dec 2020 21:33:52 -0500 Message-ID: <42178950-1ac3-27b4-a981-155fd9117969@taugh.com> From: "John R Levine" To: "Michael Thomas" Cc: "IETF DMARC WG" In-Reply-To: <8bc3c7ad-2a42-3eed-524c-8c50b16131c2@mtcc.com> References: <20201124020453.AFDC027CE5C8@ary.qy> <1eed8278-4efa-4abc-15e0-2efcf014e82e@mtcc.com> <446d491b-100a-9813-6463-2294f67bbda7@mtcc.com> <4190de2d-9f17-06d5-6354-30c989eecd4a@mtcc.com> <17d886fd-49fd-28d8-f8e4-7caf2e85919c@taugh.com> <8bc3c7ad-2a42-3eed-524c-8c50b16131c2@mtcc.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="0-1798697697-1606962558=:13447" Content-ID: Archived-At: Subject: Re: [dmarc-ietf] ARC questions X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 03 Dec 2020 02:34:05 -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-1798697697-1606962558=:13447 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT Content-ID: <5589f485-eca9-1dfa-3d8b-93c42728e3d@iecc.com> On Wed, 2 Dec 2020, Michael Thomas wrote: >> But why bother?  The IANA header field registry currently has 419 entries. >> Why is it a crisis if it increases to 422 rather than 420? > > It does a lot more than that: We've been through this all before and none of these are persuasive. For example: > 3) It adds a lot more bloat to the headers The message you just sent arrived with 4600 bytes of header (see below) and under 2K of text. Copies that went through the dmarc mailing list probably had at least another 1K of header. If header bloat were ever an issue, it hasn't been for decades. R's, John ---- snip --- Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on gal.iecc.com X-Spam-Level: X-Spam-Status: No, score=-1.5 required=4.4 tests=BAYES_00,DCC_REPUT_00_12, DKIM_SIGNED,DKIM_VALID,NICE_REPLY_A,RDNS_NONE,SPF_HELO_NONE autolearn=no autolearn_force=no version=3.4.4 Delivered-To: johnl@iecc.com Received: (qmail 70731 invoked by uid 1014); 2 Dec 2020 23:30:07 -0000 Delivered-To: virtual-taugh-johnl@taugh.com Received: (qmail 70729 invoked from network); 2 Dec 2020 23:30:07 -0000 Authentication-Results: iecc.com; spf=pass spf.mailfrom=mike@fresheez.com spf.helo=mail-pl1-x62a.google.com smtp.remote-ip="2607:f8b0:4864:20::62a"; dkim=pass header.d=mtcc-com.20150623.gappssmtp.com header.s=20150623 header.a=rsa-sha256 header.b="vvoZ+Loe" Received: from mail-pl1-x62a.google.com ([IPV6:2607:f8b0:4864:20::62a]) by mail1.iecc.com ([IPV6:2001:470:1f07:1126:33:5370:616d:6d31]) with ESMTPS via TCP6 (port 38853/25) id 665297367 tls TLS1.3_ECDHE_RSA_AES_128_GCM_AEAD sni mx1.taugh.com; 02 Dec 2020 23:30:06 -0000 Received: by mail-pl1-x62a.google.com with SMTP id 4so91499plk.5 for ; Wed, 02 Dec 2020 15:30:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mtcc-com.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=frJndGBg4PljdPRXFB1KqYuhqqDFqbuyeJjhznmBtNo=; b=vvoZ+Loew2ueICysZfzHi5UwJ3jXLN5dX+kyHN3HI91ZMJWMq7cym6dw1XQ9zaHvar KWobHhYgPlIURrzw5+sM1lArZM0+S8zElTI9oJicfts5VpsuYtc3kGzpFO58DlGQMzji +Bshah0JzXltImvCLjzUhHXHOLYvfA/Hk9lwY5XD904cTcBo4UfTKvenfFv3yLyBc4k3 l61UDIWK7HRcdixAnDYx7zJLZaO3qcbPOwkG48uqCoMDIJVhcBndL82W/JflTPy4EB9S VydV+ABOODKddInyT2i5+/cTXS1B66NWYHF/Auh1UqRkxB/+H5T//oXYkKWqXolceqkS Y3Nw== 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=frJndGBg4PljdPRXFB1KqYuhqqDFqbuyeJjhznmBtNo=; b=EiCvgdUtIHSRQXtcFgoSdo/YgcWiu1mxFOdlQ/tDw8nd2ipjfcUBNlRSW9ygClV9vu TBZpT6xrU/F0xLA6fq9Tt51Z4S1VSgDSOCt1Ut8+oLzyBXkDCjQ3j8rByKqPkRvivOap 82rO+tMd5J/4SMAAPGmJ28WAq+E7J4EJknvVu1LUOEiTERnAbmT9ZK/eTEKPjQGx0msa GMCKzawKzSfLMvOIqaKoPUmxPyrtEnEUizEPer7/aXZ0pXrUTHQ82984GTYqSdKDoYIS T+59dBxbPY9KwT33oih+1slVUSLBEbzUigK3wj4yA/71KTvr76KCUEaU8cYI6/TYcszz 2CWA== X-Gm-Message-State: AOAM530XUwEgBdQ2e02rPshm7iyXROuyhTJeAndRJAFtQO8oX1JUEgsD chdQCnyR1XB3fAEw5oIqGysS4Q== X-Google-Smtp-Source: ABdhPJzQUtiWyUp4dVxdii6hT+h4YBukyVaoJ5846n5Di6IUaEwxKrufF/3Atxm7lejww+dr4k5xIw== X-Received: by 2002:a17:90a:c4f:: with SMTP id u15mr287214pje.177.1606951804840; Wed, 02 Dec 2020 15:30:04 -0800 (PST) Return-Path: Received: from mike-mac.lan (107-182-42-33.volcanocom.com. [107.182.42.33]) by smtp.gmail.com with ESMTPSA id x7sm158495pfn.85.2020.12.02.15.30.03 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 02 Dec 2020 15:30:04 -0800 (PST) Subject: Re: [dmarc-ietf] ARC questions To: John R Levine , Brandon Long Cc: IETF DMARC WG References: <20201124020453.AFDC027CE5C8@ary.qy> <1eed8278-4efa-4abc-15e0-2efcf014e82e@mtcc.com> <446d491b-100a-9813-6463-2294f67bbda7@mtcc.com> <4190de2d-9f17-06d5-6354-30c989eecd4a@mtcc.com> <17d886fd-49fd-28d8-f8e4-7caf2e85919c@taugh.com> From: Michael Thomas Message-ID: <8bc3c7ad-2a42-3eed-524c-8c50b16131c2@mtcc.com> Date: Wed, 2 Dec 2020 15:30:01 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.5.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 --0-1798697697-1606962558=:13447-- From nobody Wed Dec 2 18: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 8DE483A0896 for ; Wed, 2 Dec 2020 18:45:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.652 X-Spam-Level: X-Spam-Status: No, score=-1.652 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mtcc-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S8o2NjgnUeIq for ; Wed, 2 Dec 2020 18:45:01 -0800 (PST) Received: from mail-pf1-x42e.google.com (mail-pf1-x42e.google.com [IPv6:2607:f8b0:4864:20::42e]) (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 CE2473A0888 for ; Wed, 2 Dec 2020 18:45:01 -0800 (PST) Received: by mail-pf1-x42e.google.com with SMTP id w6so333666pfu.1 for ; Wed, 02 Dec 2020 18:45:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mtcc-com.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=Ep42stIrfyFGejXCsrk9hMKSTcpG1lZ7Gv5rzwftTB8=; b=TcT4d02+f6FZxizTN8Uv5/g/GKrzg3Z9EqcmdPLUHvAY3tO67djRvFgrDXv43TffpF rHcnvDjfCqF4tB4617iYs8JrGXbdihqp/ZygQhhX65teujqaD0Eyb2C4sI+96jKOHjYa 0g4jv40wlJSbytiU13J5CW86Com5z1J1118D9QSreABiqveZ8Vyjs/R7Q8orwKK+Mu52 h8IxKS76BSdYM1F5qsb/hGuZC8hKJz/H1YA8OLKJREIU9fCgMA5HjO6mbAgyAWexjKxd 938Y0Nt6bXa5XvcyhG0PtZ+M19r5NcfFRLoKxz0x0f0+l4jOjCgF8eNZ059WkkvK/Kat B9ig== 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=Ep42stIrfyFGejXCsrk9hMKSTcpG1lZ7Gv5rzwftTB8=; b=tS9fSp4HHkVeJcPUEfmXNJrT0EgUEII0N3weW66SC7NCEUbfX9sgUEmt+b7rQk5uLc otD8cekvpzIsiuHwXsYrBhADJx+ojopABu5dY3v9jE+SUdyWJl6HS5KgSsHIjD37Zbyt tx/OQQ9ySCRS3tC9G42Lov6KUJihvkgjZjPuFfege0ffyLM2UB8lERiyBkxVgqUykDGg /FSyoVx6VjI5qcb1c2LCzUsD7SMjWLhGGnrvceDk7aTDg0CcK7IfiuM4ulT1nwLBsRCC 3RsGwS+aWCJ1THX9bNnI8cDwFV7zwMJBout4FNTIA1Z3SUWUgyLJkQAWzTXaH66XmnBD zFxA== X-Gm-Message-State: AOAM530ybFUIqcVWEzQwbxIl/FUiOFqU8dzssaDXlJQW2dhVy9PNxeyi +ma/oWnYzyxvHRuAKmSj5GLZ7JRBYz+spg== X-Google-Smtp-Source: ABdhPJzgwXEvkBYkLHoz7dENmQM2txZ6m6HlLPRhJGhXcylWsPSrsXmkaetzNxWZr7PTLm/fOIopgQ== X-Received: by 2002:a63:445c:: with SMTP id t28mr1113996pgk.373.1606963500878; Wed, 02 Dec 2020 18:45:00 -0800 (PST) Received: from mike-mac.lan (107-182-42-33.volcanocom.com. [107.182.42.33]) by smtp.gmail.com with ESMTPSA id w131sm383014pfd.14.2020.12.02.18.44.59 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 02 Dec 2020 18:45:00 -0800 (PST) To: John R Levine Cc: IETF DMARC WG References: <20201124020453.AFDC027CE5C8@ary.qy> <1eed8278-4efa-4abc-15e0-2efcf014e82e@mtcc.com> <446d491b-100a-9813-6463-2294f67bbda7@mtcc.com> <4190de2d-9f17-06d5-6354-30c989eecd4a@mtcc.com> <17d886fd-49fd-28d8-f8e4-7caf2e85919c@taugh.com> <8bc3c7ad-2a42-3eed-524c-8c50b16131c2@mtcc.com> <42178950-1ac3-27b4-a981-155fd9117969@taugh.com> From: Michael Thomas Message-ID: <47274049-2b07-6e99-4372-4a24dfab7de2@mtcc.com> Date: Wed, 2 Dec 2020 18:44:58 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 MIME-Version: 1.0 In-Reply-To: <42178950-1ac3-27b4-a981-155fd9117969@taugh.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] ARC questions X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 03 Dec 2020 02:45:04 -0000 On 12/2/20 6:33 PM, John R Levine wrote: > On Wed, 2 Dec 2020, Michael Thomas wrote: >>> But why bother?  The IANA header field registry currently has 419 >>> entries. Why is it a crisis if it increases to 422 rather than 420? >> >> It does a lot more than that: > > We've been through this all before and none of these are persuasive.  For > example: > So you just dismissed every other thing i wrote as insignificant and picked off one that is just calling into question why this is worth it. Sorry you are not persuasive. And you most certainly have not answered the central question of what having the previous auth-res is useful for in practice to add all of this heavy and untested machinery. Mike From nobody Wed Dec 2 18:47: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 0848B3A08B1 for ; Wed, 2 Dec 2020 18:47:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.051 X-Spam-Level: X-Spam-Status: No, score=-1.051 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URI_HEX=0.1, URI_NOVOWEL=0.5] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mtcc-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SRnwJjr692mZ for ; Wed, 2 Dec 2020 18:47:23 -0800 (PST) Received: from mail-pg1-x535.google.com (mail-pg1-x535.google.com [IPv6:2607:f8b0:4864:20::535]) (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 4B2DE3A08B0 for ; Wed, 2 Dec 2020 18:47:23 -0800 (PST) Received: by mail-pg1-x535.google.com with SMTP id o5so475201pgm.10 for ; Wed, 02 Dec 2020 18:47:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mtcc-com.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=itjYutDMFUAuzzrFwWL7OsIvT5t6iKgT1UFVGq+4XgU=; b=tVUcIBGdejZ7vFop2ghE+GZVYYya/3I3TGOvf7mMGe4LRZQOEaWYwHW5q3+kTKuL9S r1EuQ1h/Sjf9N7muwZydhVvfOBxG595NHf7CJEQDzP+hCHU7k7wU7ImbnWMP8rNxJ1z3 6qV64DwL8i05V/V0CnBv74f7FxO1koOYxR1rvWmQJuGti/ldIaAvknaiLJvKly0SEnUI 9sK9GQCvmQLWCQiPOKd0QZnPgRdiECRC6X4CB/i3LbXt03n4jkSLHpmLO9+npfVIcqXd PMy5m9PJ0jbqE3guDUDUlT5MPcvRx3id/d3aI1GpmWyNYbYNsN5zG2dAjHAxwp0ihVMH MtnA== 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=itjYutDMFUAuzzrFwWL7OsIvT5t6iKgT1UFVGq+4XgU=; b=Nq94wC9ExyOu0mVuswJShkA7p+YwZ9cHAP5tFagGk1OYKJnNqLvYuNgGplrMG0A1yk fh+uM5CXnTF70fRXp/3d0/p796HJ8TEjgrSI0g6u2sNKXQA8YZO0Kbk6XOGMs4m6KseG 2NYaRFHdAF+hweHOAQ2W0Wc3lb5VJ69ysf0A11oyTg02TLvWgpJD2UG7AtCkfo9gtfwq hvwg7PIOFys570KEdMrkGPgbXvJm5D8A5mA2DdSZ8oi6XRYcPfq3owACnK8JEgP9FbBI ArmczFdAMICHDzSQGNhnMIHHI7lWCMt1rAjMRHDYv1BVCAazl6V1g4OZRwvUJ4/hpO8r tOWA== X-Gm-Message-State: AOAM532obDlDT5S3c5bTK6PSfrasAhY3gVin8qu/VxPWFukgWintGJ2x 3TMEQJ4b5m79b+xaNKwncsH2UiERpWEqRQ== X-Google-Smtp-Source: ABdhPJw5TyN/oDQvXCuTt3qpwOC6qubHl5WT6NrS27x8Klml/M5O79b/znxgfwFboOxIbAdAeK2YJQ== X-Received: by 2002:aa7:84c5:0:b029:197:f97c:5454 with SMTP id x5-20020aa784c50000b0290197f97c5454mr1035040pfn.45.1606963642391; Wed, 02 Dec 2020 18:47:22 -0800 (PST) Received: from mike-mac.lan (107-182-42-33.volcanocom.com. [107.182.42.33]) by smtp.gmail.com with ESMTPSA id e23sm386510pfd.64.2020.12.02.18.47.21 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 02 Dec 2020 18:47:21 -0800 (PST) To: John R Levine Cc: IETF DMARC WG References: <20201124020453.AFDC027CE5C8@ary.qy> <1eed8278-4efa-4abc-15e0-2efcf014e82e@mtcc.com> <446d491b-100a-9813-6463-2294f67bbda7@mtcc.com> <4190de2d-9f17-06d5-6354-30c989eecd4a@mtcc.com> <17d886fd-49fd-28d8-f8e4-7caf2e85919c@taugh.com> <8bc3c7ad-2a42-3eed-524c-8c50b16131c2@mtcc.com> <42178950-1ac3-27b4-a981-155fd9117969@taugh.com> From: Michael Thomas Message-ID: Date: Wed, 2 Dec 2020 18:47:20 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 MIME-Version: 1.0 In-Reply-To: <42178950-1ac3-27b4-a981-155fd9117969@taugh.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] ARC questions X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 03 Dec 2020 02:47:25 -0000 PS: you're adding X-Google-DKIM-Signature which nobody knows what its utility is to your bloat total for dramatic effect. Mike On 12/2/20 6:33 PM, John R Levine wrote: > On Wed, 2 Dec 2020, Michael Thomas wrote: >>> But why bother?  The IANA header field registry currently has 419 >>> entries. Why is it a crisis if it increases to 422 rather than 420? >> >> It does a lot more than that: > > We've been through this all before and none of these are persuasive.  For > example: > >> 3) It adds a lot more bloat to the headers > > The message you just sent arrived with 4600 bytes of header (see > below) and under 2K of text.  Copies that went through the dmarc > mailing list probably had at least another 1K of header. > > If header bloat were ever an issue, it hasn't been for decades. > > R's, > John > ---- snip --- > Return-Path: > X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on gal.iecc.com > X-Spam-Level: X-Spam-Status: No, score=-1.5 required=4.4 > tests=BAYES_00,DCC_REPUT_00_12, >     DKIM_SIGNED,DKIM_VALID,NICE_REPLY_A,RDNS_NONE,SPF_HELO_NONE >     autolearn=no autolearn_force=no version=3.4.4 > Delivered-To: johnl@iecc.com > Received: (qmail 70731 invoked by uid 1014); 2 Dec 2020 23:30:07 -0000 > Delivered-To: virtual-taugh-johnl@taugh.com > Received: (qmail 70729 invoked from network); 2 Dec 2020 23:30:07 -0000 > Authentication-Results: iecc.com; spf=pass > spf.mailfrom=mike@fresheez.com spf.helo=mail-pl1-x62a.google.com > smtp.remote-ip="2607:f8b0:4864:20::62a"; dkim=pass > header.d=mtcc-com.20150623.gappssmtp.com header.s=20150623 > header.a=rsa-sha256 header.b="vvoZ+Loe" > Received: from mail-pl1-x62a.google.com ([IPV6:2607:f8b0:4864:20::62a]) >   by mail1.iecc.com ([IPV6:2001:470:1f07:1126:33:5370:616d:6d31]) >   with ESMTPS via TCP6 (port 38853/25) id 665297367 >   tls TLS1.3_ECDHE_RSA_AES_128_GCM_AEAD sni mx1.taugh.com; 02 Dec 2020 > 23:30:06 -0000 > Received: by mail-pl1-x62a.google.com with SMTP id 4so91499plk.5 >         for ; Wed, 02 Dec 2020 15:30:05 -0800 (PST) > DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; >         d=mtcc-com.20150623.gappssmtp.com; s=20150623; >         h=subject:to:cc:references:from:message-id:date:user-agent > :mime-version:in-reply-to:content-transfer-encoding:content-language; >         bh=frJndGBg4PljdPRXFB1KqYuhqqDFqbuyeJjhznmBtNo=; > b=vvoZ+Loew2ueICysZfzHi5UwJ3jXLN5dX+kyHN3HI91ZMJWMq7cym6dw1XQ9zaHvar > KWobHhYgPlIURrzw5+sM1lArZM0+S8zElTI9oJicfts5VpsuYtc3kGzpFO58DlGQMzji > +Bshah0JzXltImvCLjzUhHXHOLYvfA/Hk9lwY5XD904cTcBo4UfTKvenfFv3yLyBc4k3 > l61UDIWK7HRcdixAnDYx7zJLZaO3qcbPOwkG48uqCoMDIJVhcBndL82W/JflTPy4EB9S > VydV+ABOODKddInyT2i5+/cTXS1B66NWYHF/Auh1UqRkxB/+H5T//oXYkKWqXolceqkS >          Y3Nw== > 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=frJndGBg4PljdPRXFB1KqYuhqqDFqbuyeJjhznmBtNo=; > b=EiCvgdUtIHSRQXtcFgoSdo/YgcWiu1mxFOdlQ/tDw8nd2ipjfcUBNlRSW9ygClV9vu > TBZpT6xrU/F0xLA6fq9Tt51Z4S1VSgDSOCt1Ut8+oLzyBXkDCjQ3j8rByKqPkRvivOap > 82rO+tMd5J/4SMAAPGmJ28WAq+E7J4EJknvVu1LUOEiTERnAbmT9ZK/eTEKPjQGx0msa > GMCKzawKzSfLMvOIqaKoPUmxPyrtEnEUizEPer7/aXZ0pXrUTHQ82984GTYqSdKDoYIS > T+59dBxbPY9KwT33oih+1slVUSLBEbzUigK3wj4yA/71KTvr76KCUEaU8cYI6/TYcszz >          2CWA== > X-Gm-Message-State: > AOAM530XUwEgBdQ2e02rPshm7iyXROuyhTJeAndRJAFtQO8oX1JUEgsD >     chdQCnyR1XB3fAEw5oIqGysS4Q== > X-Google-Smtp-Source: > ABdhPJzQUtiWyUp4dVxdii6hT+h4YBukyVaoJ5846n5Di6IUaEwxKrufF/3Atxm7lejww+dr4k5xIw== > X-Received: by 2002:a17:90a:c4f:: with SMTP id > u15mr287214pje.177.1606951804840; >         Wed, 02 Dec 2020 15:30:04 -0800 (PST) > Return-Path: > Received: from mike-mac.lan (107-182-42-33.volcanocom.com. > [107.182.42.33]) >         by smtp.gmail.com with ESMTPSA id > x7sm158495pfn.85.2020.12.02.15.30.03 >         (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); >         Wed, 02 Dec 2020 15:30:04 -0800 (PST) > Subject: Re: [dmarc-ietf] ARC questions > To: John R Levine , Brandon Long > Cc: IETF DMARC WG > References: <20201124020453.AFDC027CE5C8@ary.qy> >   >   >   >   >  <1eed8278-4efa-4abc-15e0-2efcf014e82e@mtcc.com> >   >  <446d491b-100a-9813-6463-2294f67bbda7@mtcc.com> >   >  <4190de2d-9f17-06d5-6354-30c989eecd4a@mtcc.com> >  <17d886fd-49fd-28d8-f8e4-7caf2e85919c@taugh.com> >   >   > From: Michael Thomas > Message-ID: <8bc3c7ad-2a42-3eed-524c-8c50b16131c2@mtcc.com> > Date: Wed, 2 Dec 2020 15:30:01 -0800 > User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) >  Gecko/20100101 Thunderbird/78.5.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 From nobody Wed Dec 2 18: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 686B03A091B for ; Wed, 2 Dec 2020 18:58:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.051 X-Spam-Level: X-Spam-Status: No, score=-1.051 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URI_HEX=0.1, URI_NOVOWEL=0.5] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mtcc-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RG5ePVk2nGtJ for ; Wed, 2 Dec 2020 18:58:32 -0800 (PST) Received: from mail-pl1-x62f.google.com (mail-pl1-x62f.google.com [IPv6:2607:f8b0:4864:20::62f]) (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 4F3573A0911 for ; Wed, 2 Dec 2020 18:58:32 -0800 (PST) Received: by mail-pl1-x62f.google.com with SMTP id v3so317158plz.13 for ; Wed, 02 Dec 2020 18:58:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mtcc-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=pNnIKuvwIxr9MaXU5b0uNH4+i29nKTvBfNcbW29BVuk=; b=GlRCq+EjcBzEdtN/R34QYE/PcE2MCBRwduW7gsdDPVeM8D+HbuBUPT/XNPVKZLtved dx3dMnyzyNU9kNVx9hrg8B8HMUz8y0EQIS6bg5pY+8VAAN0J28mpddH/cCyq+7w2RO+r Qctq6oIGhxCVLqkg7AFZEq+DgUlTn3RzssuGDxQYLHhJ+PucYp/ZeVeD9ELWRXOq0zQ6 plwtSp468dkkyfZgi1FvWj4HKtUlGZHME91juEdG6lqCACdVbLC4xFfDVuwEbDaT6EMx KCKO8QZ/1I+vugU2qK7WCAEtaE/jtafSaUb6vacJrUJjSJbuZ4DEEimWR9zIuA2k3ViX DKnw== 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=pNnIKuvwIxr9MaXU5b0uNH4+i29nKTvBfNcbW29BVuk=; b=XoM7xiBpnuHEAHM8em9UDzciFm3+E6zOgqErbNrhKLG0S5d1/6M72zkHwejkrg+ooT I40jJZD8YBWn+RyeXdKUgFYnzKm1duVhuKMbWBYii/ZA6X1REWhdk/2khgEt6xU4XM6x kW2YOU1O9DAivirDB/QwDP8KXqAMrHM6bGVpMXkelGgofkRSSyEqAA4oi6SuDpPOg4y0 wk2HcCZ8r0oVbUaof39yX3X43mfYZolmg/LG4ylkRMrtUKpyuCKrjOykR2f/4Bl3aT4E aZ5sehk9iADsPa7vq12ndoz/rNvb5rHupvg5JRJ5iLmSuZpKWubvxfe27FSj1GqcqpzF m52A== X-Gm-Message-State: AOAM530JpVJtFhHI8ROTdD/SKzTvvw6iPzq6bxynK6UE+o2Mtgje4k7v j5R10t8+iAhlVucniompik4KYoIspv2e9w== X-Google-Smtp-Source: ABdhPJzmZiYilq5DHTvoagIgbuzNQjXrTvYRDNOnZV8c+IFYI/5Of+wTo/RsrWgmEuQq8acP5FOEng== X-Received: by 2002:a17:90a:b118:: with SMTP id z24mr1024159pjq.14.1606964311198; Wed, 02 Dec 2020 18:58:31 -0800 (PST) Received: from mike-mac.lan (107-182-42-33.volcanocom.com. [107.182.42.33]) by smtp.gmail.com with ESMTPSA id b28sm393269pfp.195.2020.12.02.18.58.29 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 02 Dec 2020 18:58:30 -0800 (PST) To: "John R. Levine" , "dmarc@ietf.org" References: <20201124020453.AFDC027CE5C8@ary.qy> <1eed8278-4efa-4abc-15e0-2efcf014e82e@mtcc.com> <446d491b-100a-9813-6463-2294f67bbda7@mtcc.com> <4190de2d-9f17-06d5-6354-30c989eecd4a@mtcc.com> <17d886fd-49fd-28d8-f8e4-7caf2e85919c@taugh.com> <8bc3c7ad-2a42-3eed-524c-8c50b16131c2@mtcc.com> <42178950-1ac3-27b4-a981-155fd9117969@taugh.com> <70bd5e9-f0e8-3bdf-c5f0-6428841e1577@iecc.com> From: Michael Thomas Message-ID: <162586f5-d565-0e4f-955d-8ceca1d569d2@mtcc.com> Date: Wed, 2 Dec 2020 18:58:28 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 MIME-Version: 1.0 In-Reply-To: <70bd5e9-f0e8-3bdf-c5f0-6428841e1577@iecc.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] ARC questions X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 03 Dec 2020 02:58:34 -0000 if you're trying to make a point about the bloat, you might actually get your facts straight. ARC adds an additional DKIM signature and a Seal. i have no idea what a X-Google-DKIM-Signature is and is not relevant. Mike On 12/2/20 6:55 PM, John R. Levine wrote: >> PS: you're adding X-Google-DKIM-Signature which nobody knows what its >> utility is to your bloat total for dramatic effect. > > Um, it was there when your message arrived here.  Complain to your > mail provider. > >> On 12/2/20 6:33 PM, John R Levine wrote: >>> On Wed, 2 Dec 2020, Michael Thomas wrote: >>>>> But why bother?  The IANA header field registry currently has 419 >>>>> entries. Why is it a crisis if it increases to 422 rather than 420? >>>> >>>> It does a lot more than that: >>> >>> We've been through this all before and none of these are >>> persuasive.  For >>> example: >>> >>>> 3) It adds a lot more bloat to the headers >>> >>> The message you just sent arrived with 4600 bytes of header (see >>> below) and under 2K of text.  Copies that went through the dmarc >>> mailing list probably had at least another 1K of header. >>> >>> If header bloat were ever an issue, it hasn't been for decades. >>> >>> R's, >>> John >>> ---- snip --- >>> Return-Path: >>> X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on gal.iecc.com >>> X-Spam-Level: X-Spam-Status: No, score=-1.5 required=4.4 >>> tests=BAYES_00,DCC_REPUT_00_12, >>>     DKIM_SIGNED,DKIM_VALID,NICE_REPLY_A,RDNS_NONE,SPF_HELO_NONE >>>     autolearn=no autolearn_force=no version=3.4.4 >>> Delivered-To: johnl@iecc.com >>> Received: (qmail 70731 invoked by uid 1014); 2 Dec 2020 23:30:07 -0000 >>> Delivered-To: virtual-taugh-johnl@taugh.com >>> Received: (qmail 70729 invoked from network); 2 Dec 2020 23:30:07 -0000 >>> Authentication-Results: iecc.com; spf=pass >>> spf.mailfrom=mike@fresheez.com spf.helo=mail-pl1-x62a.google.com >>> smtp.remote-ip="2607:f8b0:4864:20::62a"; dkim=pass >>> header.d=mtcc-com.20150623.gappssmtp.com header.s=20150623 >>> header.a=rsa-sha256 header.b="vvoZ+Loe" >>> Received: from mail-pl1-x62a.google.com ([IPV6:2607:f8b0:4864:20::62a]) >>>   by mail1.iecc.com ([IPV6:2001:470:1f07:1126:33:5370:616d:6d31]) >>>   with ESMTPS via TCP6 (port 38853/25) id 665297367 >>>   tls TLS1.3_ECDHE_RSA_AES_128_GCM_AEAD sni mx1.taugh.com; 02 Dec >>> 2020 23:30:06 -0000 >>> Received: by mail-pl1-x62a.google.com with SMTP id 4so91499plk.5 >>>         for ; Wed, 02 Dec 2020 15:30:05 -0800 (PST) >>> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; >>>         d=mtcc-com.20150623.gappssmtp.com; s=20150623; >>> h=subject:to:cc:references:from:message-id:date:user-agent >>> :mime-version:in-reply-to:content-transfer-encoding:content-language; >>>         bh=frJndGBg4PljdPRXFB1KqYuhqqDFqbuyeJjhznmBtNo=; >>> b=vvoZ+Loew2ueICysZfzHi5UwJ3jXLN5dX+kyHN3HI91ZMJWMq7cym6dw1XQ9zaHvar >>> KWobHhYgPlIURrzw5+sM1lArZM0+S8zElTI9oJicfts5VpsuYtc3kGzpFO58DlGQMzji >>> +Bshah0JzXltImvCLjzUhHXHOLYvfA/Hk9lwY5XD904cTcBo4UfTKvenfFv3yLyBc4k3 >>> l61UDIWK7HRcdixAnDYx7zJLZaO3qcbPOwkG48uqCoMDIJVhcBndL82W/JflTPy4EB9S >>> VydV+ABOODKddInyT2i5+/cTXS1B66NWYHF/Auh1UqRkxB/+H5T//oXYkKWqXolceqkS >>>          Y3Nw== >>> 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=frJndGBg4PljdPRXFB1KqYuhqqDFqbuyeJjhznmBtNo=; >>> b=EiCvgdUtIHSRQXtcFgoSdo/YgcWiu1mxFOdlQ/tDw8nd2ipjfcUBNlRSW9ygClV9vu >>> TBZpT6xrU/F0xLA6fq9Tt51Z4S1VSgDSOCt1Ut8+oLzyBXkDCjQ3j8rByKqPkRvivOap >>> 82rO+tMd5J/4SMAAPGmJ28WAq+E7J4EJknvVu1LUOEiTERnAbmT9ZK/eTEKPjQGx0msa >>> GMCKzawKzSfLMvOIqaKoPUmxPyrtEnEUizEPer7/aXZ0pXrUTHQ82984GTYqSdKDoYIS >>> T+59dBxbPY9KwT33oih+1slVUSLBEbzUigK3wj4yA/71KTvr76KCUEaU8cYI6/TYcszz >>>          2CWA== >>> X-Gm-Message-State: >>> AOAM530XUwEgBdQ2e02rPshm7iyXROuyhTJeAndRJAFtQO8oX1JUEgsD >>>     chdQCnyR1XB3fAEw5oIqGysS4Q== >>> X-Google-Smtp-Source: >>> ABdhPJzQUtiWyUp4dVxdii6hT+h4YBukyVaoJ5846n5Di6IUaEwxKrufF/3Atxm7lejww+dr4k5xIw== >>> X-Received: by 2002:a17:90a:c4f:: with SMTP id >>> u15mr287214pje.177.1606951804840; >>>         Wed, 02 Dec 2020 15:30:04 -0800 (PST) >>> Return-Path: >>> Received: from mike-mac.lan (107-182-42-33.volcanocom.com. >>> [107.182.42.33]) >>>         by smtp.gmail.com with ESMTPSA id >>> x7sm158495pfn.85.2020.12.02.15.30.03 >>>         (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); >>>         Wed, 02 Dec 2020 15:30:04 -0800 (PST) >>> Subject: Re: [dmarc-ietf] ARC questions >>> To: John R Levine , Brandon Long >>> Cc: IETF DMARC WG >>> References: <20201124020453.AFDC027CE5C8@ary.qy> >>>   >>>   >>>   >>>   >>>  <1eed8278-4efa-4abc-15e0-2efcf014e82e@mtcc.com> >>>   >>>  <446d491b-100a-9813-6463-2294f67bbda7@mtcc.com> >>>   >>>  <4190de2d-9f17-06d5-6354-30c989eecd4a@mtcc.com> >>>  <17d886fd-49fd-28d8-f8e4-7caf2e85919c@taugh.com> >>>   >>>   >>> From: Michael Thomas >>> Message-ID: <8bc3c7ad-2a42-3eed-524c-8c50b16131c2@mtcc.com> >>> Date: Wed, 2 Dec 2020 15:30:01 -0800 >>> User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) >>>  Gecko/20100101 Thunderbird/78.5.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 >> >> > > 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 Wed Dec 2 20:30: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 6445F3A0AB4 for ; Wed, 2 Dec 2020 20:30:14 -0800 (PST) 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 tHyUX-Rvdsxq for ; Wed, 2 Dec 2020 20:30:12 -0800 (PST) Received: from mail-qv1-xf36.google.com (mail-qv1-xf36.google.com [IPv6:2607:f8b0:4864:20::f36]) (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 8D6783A0AB5 for ; Wed, 2 Dec 2020 20:30:12 -0800 (PST) Received: by mail-qv1-xf36.google.com with SMTP id ek7so383742qvb.6 for ; Wed, 02 Dec 2020 20:30:12 -0800 (PST) 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=YrKLNGtrh8tYTIFPldVnTpD7iTX6MAPs4XcAUcuBLO0=; b=JhKz2+fTHZu2BtGGObYm2GzzMgnN/zhMP2IXKAI5ap7Tt/hGjhpFXtdHQbnsNapubz rSX7Pv1AeE3btTeiBfT6JNXRNJtHKoazIEnsxPJe/IHzJYd5MeMMiMjxbH5+NWIcquch BfkaOxEEHnfi6poQ9cdGRHkVB5yKFWuPl+JyeQ+ay94JVXm5B5tTjX079KiQoTLsLDWe KYXJK3MOYwt6sw5iAU4BCUCPS+a1OpLqBJGnTtqgS9hIXLbGFKeccPU9SRB+y4YzVUrd GkNM94xzC4jEE2mW0Hh2fL1nSUa5UbhdYouXBI3KzJP1Xd2CSh9fXAszQnvucQxVCg+I sPTw== 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=YrKLNGtrh8tYTIFPldVnTpD7iTX6MAPs4XcAUcuBLO0=; b=bXwzQjiPWpjP1vf0mr5QolaklvnfGNlpbUiIzFrfGDo+Ua0SgZu/vPdTJVS/mdg0fD blKOtGAdGl7VgHPrWbrJyiCXkb4QO7USGfeq/hoazETJAgLT5TbWgXDlZVNC6uCWvXUh vlIUWoaJRLjX2RuSbLRQVOsVqFQoUjHsmKDvXbDMTOWjIinPEejhmhTXfafcMdTlrOJD zixwJP/ejBPCL9T8PySbduo4anQYF2NUsYusR87iWowcCQRjbRgaeXsHXHKbqd5DY3NF vF+y9Reeln/TzpF3a/u1Uh0VXNfuq9AVuvcyAa+jUhPWKpl+TIOiVq0A19yC9JY1k0l6 5ntw== X-Gm-Message-State: AOAM531wNY9bViJb3pqqOQHTk8SDm3w/Cs3yn6Um24K8oLlP+f+Ueei0 H3xVZW/TRlPuQIsQfLbbvexmBgthCTAtiGL2BcRP7nWmuDQ= X-Google-Smtp-Source: ABdhPJxbrqTHvsyLYla9elFrwxjw5Dbw2zVv6jvPad282DErWwk2UBoIhSTvZmsE2Vvxo8I3oe9E3V4TxbUx/LmyLAI= X-Received: by 2002:a0c:e6e7:: with SMTP id m7mr1317452qvn.11.1606969811435; Wed, 02 Dec 2020 20:30:11 -0800 (PST) MIME-Version: 1.0 References: <20201202021651.E8EE128C576A@ary.qy> <327860af-2fa7-63ee-4b89-6e7e383f3d53@crash.com> <2804da89-84d1-f601-9425-0b0d9baf6ae1@gmail.com> <1f6cae74-4eed-47f5-7249-e526bf1f5845@crash.com> <87y2ig9t9i.fsf@orion.amorsen.dk> <87r1o7alag.fsf@orion.amorsen.dk> In-Reply-To: <87r1o7alag.fsf@orion.amorsen.dk> From: Dotzero Date: Wed, 2 Dec 2020 23:29:59 -0500 Message-ID: To: Benny Lyne Amorsen Cc: IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000c6882a05b587d091" Archived-At: Subject: Re: [dmarc-ietf] Ticket #39 - remove p=quarantine X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 03 Dec 2020 04:30:14 -0000 --000000000000c6882a05b587d091 Content-Type: text/plain; charset="UTF-8" On Wed, Dec 2, 2020 at 5:35 PM Benny Lyne Amorsen wrote: > Dotzero writes: > > > p= DID NOT mistakenly choose to use the language of receiver > > actions. p= represents the domain-owner request to the receiver as to > > the disposition of messages which fail to validate. Any reading of > > "concern" is supposition on the part of yourself or other self > > appointed interpreters of the mind of the domain-owner or > > administrator. [..] This is an interoperability standard, not a > > seance. > > Am I particularly thin-skinned for considering this language > inflammatory? > Your assertion that the drafters of DMARC mistakenly chose the language of receivers is inflammatory. I don't remember you as part of the group that developed DMARC. To make assertions regarding what people were thinking when one wasn't present falls into the same realm as seances. > > The thing is, domain owners can request anything they want, but why > should anyone listen? Particularly if they are rude about it instead of > asking nicely. > The thing is, Validators and Receivers will do what they will do. It is important to remember that DMARC only allows for "neutral" statements (no policy) or negative assertions (quarantine or reject). It does not allow for positive assertions (deliver my message to the inbox) nor does it allow assertions for anything except the domain owners own domain) To the extent that domain owner requests make sense they will be considered and used by Validators and Receivers. To the extent they don't, they won't be used. It really is that simple. Would any Validator or Receiver take seriously a DMARC policy assertion of p=reject based on an SPF record using *0.0.0.0/0* -all? Doubtful. > > When someone brings up a concern they have and explain why it is of > benefit to either the recipient or the community to take certain > actions, that will likely be heard. However, unexplained edicts are > unlikely to be taken very seriously. > How seriously should someone's "concern" be taken when it is phrased as an assertion of knowing what was in the minds of people when that someone wasn't present. That someone might have phrased it as a question rather than a declarative. As far as unexplained "edicts", quite a few receivers use SPF/DKIM/DMARC in their calculus as to how they handle mail destined for their systems. So there is clearly some perceived benefit or they wouldn't be doing so. Michael Hammer --000000000000c6882a05b587d091 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Dec 2, 2020 at 5:35 PM Benny = Lyne Amorsen <benny+usenet@= amorsen.dk> wrote:
Dotzero <dotzero@gmail.com> writes:

> p=3D DID NOT mistakenly choose to use the language of receiver
> actions. p=3D represents the domain-owner request to the receiver as t= o
> the disposition of messages which fail to validate. Any reading of
> "concern" is supposition on the part of yourself or other se= lf
> appointed interpreters of the mind of the domain-owner or
> administrator. [..] This is an interoperability standard, not a
> seance.

Am I particularly thin-skinned for considering this language
inflammatory?

Your assertion that the d= rafters of DMARC mistakenly chose the language of receivers is inflammatory= . I don't remember you as part of the group that developed DMARC. To ma= ke assertions regarding what people were thinking when one wasn't prese= nt falls into the same realm as seances.

The thing is, domain owners can request anything they want, but why
should anyone listen? Particularly if they are rude about it instead of
asking nicely.

The thing is, Validators= and Receivers will do what they will do. It is important to remember that = DMARC only allows for "neutral" statements (no policy) or negativ= e assertions (quarantine or reject). It does not allow for positive asserti= ons (deliver my message to the inbox) nor does it allow assertions for anyt= hing except the domain owners own domain) To the extent that domain owner r= equests make sense they will be considered and used by Validators and Recei= vers. To the extent they don't, they won't be used. It really is th= at simple. Would any Validator or Receiver take seriously a DMARC policy as= sertion of p=3Dreject based on an SPF record using=C2=A0 0.0.0.0/0 -all? Doubtful.

When someone brings up a concern they have and explain why it is of
benefit to either the recipient or the community to take certain
actions, that will likely be heard. However, unexplained edicts are
unlikely to be taken very seriously.

Ho= w seriously should someone's "concern" be taken when it is ph= rased as an assertion of knowing what was in the minds of people when that = someone wasn't present. That someone might have phrased it as a questio= n rather than a declarative. As far as unexplained "edicts", quit= e a few receivers use SPF/DKIM/DMARC in their calculus as to how they handl= e mail destined for their systems. So there is clearly some perceived benef= it or they wouldn't be doing so.

Michael Hamme= r


--000000000000c6882a05b587d091-- From nobody Wed Dec 2 21:52: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 C900D3A0C26 for ; Wed, 2 Dec 2020 21:52:25 -0800 (PST) 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 yBveaTLq52aS for ; Wed, 2 Dec 2020 21:52:23 -0800 (PST) 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 473053A0D69 for ; Wed, 2 Dec 2020 21:51:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bluepopcorn.net; s=supersize; h=Content-Transfer-Encoding:Content-Type: MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From:Sender :Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=V/dOTPZF36viFun8cLGLqSz2GXwjtjyt/HDNgvmqEMk=; b=fSQIktaxgg42fSaZflmbnhh1c/ CTHL2uVmhkjf5FMH0+WVoabPD/g7ftE658TOM1/pxcL23t/eO0H3fyt0CtP/5JjPePI1To9xABOBY PvGbgsY1aEi0NX8I2osoQ9aTM/8ErfrDbssbNx8CaAoFhubl85xd0ph+HibUgY0hbheE=; Received: from [2601:647:4400:1261:814f:cf27:ab65:355] (helo=[10.10.20.144]) by v2.bluepopcorn.net with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kkhWd-00079N-VT; Wed, 02 Dec 2020 21:51:32 -0800 From: "Jim Fenton" To: "Steven M Jones" Cc: dmarc@ietf.org Date: Wed, 02 Dec 2020 21:51:31 -0800 X-Mailer: MailMate (1.13.2r5673) Message-ID: <10179782-887D-4C27-A1A0-E2BCB9E5A0A4@bluepopcorn.net> In-Reply-To: References: <2fc01257-3307-c453-18a0-bc423dccfe6a@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] Ticket #39 - remove p=quarantine X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 03 Dec 2020 05:52:26 -0000 On 1 Dec 2020, at 17:42, Steven M Jones wrote: > On 12/1/20 4:16 PM, Douglas Foster wrote: > I really hope no casual readers get the impression that DMARC bypasses > spam filtering. DMARC evaluations are expected to be independent of > spam evaluations. If there's any overlap here, perhaps it would be for > DMARC (and/or underlying protocols) to provide reliable domain > attribution to drive a local policy decision about filtering. Agree about not bypassing spam filtering. But not about the “independent of spam evaluations” part. Spam filters are going to use any message characteristic that they find useful, including whether the message is signed, passes SPF, has an aligned From address, has a DMARC record of a certain type, etc. to make a decision. It’s what spam filters do, and we have no say about that. -Jim From nobody Wed Dec 2 22:03: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 4059E3A00C4 for ; Wed, 2 Dec 2020 22:03:27 -0800 (PST) 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 7VHAbKHi6mgC for ; Wed, 2 Dec 2020 22:03:25 -0800 (PST) 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 AA0753A0062 for ; Wed, 2 Dec 2020 22:03:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bluepopcorn.net; s=supersize; h=Content-Transfer-Encoding:Content-Type: MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From:Sender :Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=HHn7IM7L/L0pGGjJbWRpRjG8VaCSeUwSFSMYfHTozlg=; b=U5HWQXv5YptWxfFaU2m9I4TOZS vZHKE33SjPm2yLP5mBsDMxN/boiYY+Yc3sPEBMAL9sm+daKqsHa/VMSaAHFLDJ5Jg8sc+6d/vgyd7 ltSHBtLNcJqyKwk7fix2syPelqejyP3wd15K1MRMxzQkcObSalY1BOL1o1m8FUQF5pRg=; Received: from [2601:647:4400:1261:814f:cf27:ab65:355] (helo=[10.10.20.144]) by v2.bluepopcorn.net with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kkhi8-0007Av-RX; Wed, 02 Dec 2020 22:03:25 -0800 From: "Jim Fenton" To: "Laura Atkins" Cc: "IETF DMARC WG" Date: Wed, 02 Dec 2020 22:03:24 -0800 X-Mailer: MailMate (1.13.2r5673) Message-ID: In-Reply-To: <5C559553-3F45-494D-9714-F7BC47BB82FF@wordtothewise.com> References: <5C559553-3F45-494D-9714-F7BC47BB82FF@wordtothewise.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] Ticket #39 - remove p=quarantine X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 03 Dec 2020 06:03:27 -0000 On 2 Dec 2020, at 1:47, Laura Atkins wrote: > p=quarantine is quite useful, particularly for those folks who are > trying to get to a p=reject state. > > In practice, senders who publish p=none don’t find all of the > indirect mail flows as some mailing lists do nothing to transform the > 5322.from address for a p=none policy. Senders have found that when > they switch from p=none to p=quarantine pct=0 they regularly find mail > that was not failing for a p=none. I’m really confused by this. It sounds like the 5322.from address rewriting is creating additional errors that didn’t exist beforehand, and that’s the opposite of the intended purpose. Isn’t the purpose of rewriting the 5322.from address to change the domain to that of the mediator, which should redirect reporting to the mediator rather than the original sender? -Jim From nobody Wed Dec 2 22:12: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 0E1FC3A0115 for ; Wed, 2 Dec 2020 22:12:14 -0800 (PST) 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 MJIRfvf7KPXV for ; Wed, 2 Dec 2020 22:12:12 -0800 (PST) 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 939113A0100 for ; Wed, 2 Dec 2020 22:12:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bluepopcorn.net; s=supersize; h=Content-Transfer-Encoding:Content-Type: MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From:Sender :Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=LB1wUCsZNV/L/1rbRAhi5pGObDg2EWJMvcAo+FA2zA8=; b=dssLIvUakHammPM4Agrq5D99X5 Q2dpLKSC5i2sRsNibFkkRpG8dYjJOAiPJmDbmMvu/c+BKEDMkYsWeV+uL5ktj0+7sDl8daGOMnWYd 82LK/Y8/2b3AdNYxZEaCGA+0IQT7V6tRRv2Lu1KTfUzxruPyZ9lToXd6hIgMTxLRgi8g=; Received: from [2601:647:4400:1261:814f:cf27:ab65:355] (helo=[10.10.20.144]) by v2.bluepopcorn.net with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kkhqc-0007Dq-5M; Wed, 02 Dec 2020 22:12:11 -0800 From: "Jim Fenton" To: "Dave Crocker" Cc: dmarc@ietf.org Date: Wed, 02 Dec 2020 22:12:09 -0800 X-Mailer: MailMate (1.13.2r5673) Message-ID: In-Reply-To: References: <20201202021651.E8EE128C576A@ary.qy> <327860af-2fa7-63ee-4b89-6e7e383f3d53@crash.com> <2804da89-84d1-f601-9425-0b0d9baf6ae1@gmail.com> <1f6cae74-4eed-47f5-7249-e526bf1f5845@crash.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_8062A2FE-F959-4E71-9BBA-9EADD8D007AA_=" Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] Ticket #39 - remove p=quarantine X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 03 Dec 2020 06:12:14 -0000 --=_MailMate_8062A2FE-F959-4E71-9BBA-9EADD8D007AA_= Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit On 2 Dec 2020, at 6:09, Dave Crocker wrote: > *none*: The Domain Owner offers no expression of concern. > > *quarantine:* The Domain Owner considers such mail to be > suspicious. It is possible the mail is valid, although the > failure creates a significant concern. > > *reject: *The Domain Owner considers all such failures to be a > clear indication that the use of the domain name is not > valid.  > See Section 10.3 > for some > discussion of SMTP rejection methods and their implications. The problem is that _quarantine_ and _reject_ are imperative verbs. The specification can use any definition, but if it uses imperative words, they are going to be taken as imperative. Maybe _discardable_ should be used instead. Why do I have a feeling of deja vu? -Jim --=_MailMate_8062A2FE-F959-4E71-9BBA-9EADD8D007AA_= Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On 2 Dec 2020, at 6:09, Dave Crocker wrote:

= *none*: The Domain Owner offers no expression of concern.

*quarantine:* The Domain Owner considers such mail to be
suspicious. It is possible the mail is valid, although the
failure creates a significant concern.

*reject: *The Domain Owner considers all such failures to be a
= clear indication that the use of the domain name is not valid.=C2=A0=
See Section 10.3
<https://tools.ietf.org/html/rfc7489#section-10.3&= gt; for some
discussion of SMTP rejection methods and their implications.

The problem is that quarantine and reject are imperative verbs. The specification can use any definition, but if= it uses imperative words, they are going to be taken as imperative.

Maybe discardable should be used instead.

Why do I have a feeling of deja vu?

-Jim

--=_MailMate_8062A2FE-F959-4E71-9BBA-9EADD8D007AA_=-- From nobody Thu Dec 3 01:28: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 E5CE63A0D79 for ; Thu, 3 Dec 2020 01:28:26 -0800 (PST) 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 o0I8jMkM0APQ for ; Thu, 3 Dec 2020 01:28:25 -0800 (PST) Received: from mail.wordtothewise.com (mail.wordtothewise.com [104.225.223.158]) by ietfa.amsl.com (Postfix) with ESMTP id 30C613A0D75 for ; Thu, 3 Dec 2020 01:28:24 -0800 (PST) Received: from [192.168.0.227] (unknown [37.228.231.27]) by mail.wordtothewise.com (Postfix) with ESMTPSA id AB62A9F149 for ; Thu, 3 Dec 2020 01:28:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=wordtothewise.com; s=aardvark; t=1606987704; bh=3e7UR+YybCgJLHyuV63Uuaccpbwt5VsKaIbf9/cAOY4=; h=From:Subject:Date:References:To:In-Reply-To:From; b=BsaUqu9LIUvUolMTRTSmoDJEMp+jgrs/g9E0Rj/Ig5Zo6qPD2BFU9nAV1FIz9QbRC HFNsC/eE3j5I3TzXKNYtwj3ukz90kbCSq6kbWjO62+ATQpm/KZDHd5PJA1a1f2Re7U IpguTebap9e9jrAuu/BrG5GXTmrBjoqHfQFlzJTw= From: Laura Atkins Content-Type: multipart/alternative; boundary="Apple-Mail=_B6A33DFF-BD92-46DC-B9D0-42F5F07324FB" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Date: Thu, 3 Dec 2020 09:28:21 +0000 References: <5C559553-3F45-494D-9714-F7BC47BB82FF@wordtothewise.com> To: IETF DMARC WG In-Reply-To: Message-Id: <2F1BED43-5AE5-42BC-AA45-67C5FDAF6CB8@wordtothewise.com> X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [dmarc-ietf] Ticket #39 - remove p=quarantine X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 03 Dec 2020 09:28:27 -0000 --Apple-Mail=_B6A33DFF-BD92-46DC-B9D0-42F5F07324FB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 3 Dec 2020, at 06:03, Jim Fenton wrote: >=20 > On 2 Dec 2020, at 1:47, Laura Atkins wrote: >=20 >> p=3Dquarantine is quite useful, particularly for those folks who are = trying to get to a p=3Dreject state. >>=20 >> In practice, senders who publish p=3Dnone don=E2=80=99t find all of = the indirect mail flows as some mailing lists do nothing to transform = the 5322.from address for a p=3Dnone policy. Senders have found that = when they switch from p=3Dnone to p=3Dquarantine pct=3D0 they regularly = find mail that was not failing for a p=3Dnone. >=20 > I=E2=80=99m really confused by this. It sounds like the 5322.from = address rewriting is creating additional errors that didn=E2=80=99t = exist beforehand, and that=E2=80=99s the opposite of the intended = purpose. Isn=E2=80=99t the purpose of rewriting the 5322.from address to = change the domain to that of the mediator, which should redirect = reporting to the mediator rather than the original sender? What I am trying to say is that as I understand it from the folks who = professionally deploy DMARC, they regularly use p=3Dquarantine pct=3D0 = as part of the deployment process. There are DMARC failures that go = undetected in a p=3Dnone situation but that is detected in a = p=3Dquarantine pct=3D0 situation. My understanding was this was = related to indirect flows through mailing lists and how mailing lists = are handling the header transformation but it=E2=80=99s possible I got = that piece incorrect.=20 p=3Dquarantine is valuable for other reasons as well, and I think it = should be kept.=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=_B6A33DFF-BD92-46DC-B9D0-42F5F07324FB Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On 3 Dec 2020, at 06:03, Jim Fenton <fenton@bluepopcorn.net> wrote:

On 2 = Dec 2020, at 1:47, Laura Atkins wrote:

p=3Dquarantine is quite = useful, particularly for those folks who are trying to get to a p=3Dreject= state.

In practice, senders who publish = p=3Dnone don=E2=80=99t find all of the indirect mail flows as some = mailing lists do nothing to transform the 5322.from address for a p=3Dnone= policy. Senders have found that when they switch from p=3Dnone to = p=3Dquarantine pct=3D0 they regularly find mail that was not failing for = a p=3Dnone.

I=E2=80=99m really = confused by this. It sounds like the 5322.from address rewriting is = creating additional errors that didn=E2=80=99t exist beforehand, and = that=E2=80=99s the opposite of the intended purpose. Isn=E2=80=99t the = purpose of rewriting the 5322.from address to change the domain to that = of the mediator, which should redirect reporting to the mediator rather = than the original sender?

What I am trying to say is that as I understand it = from the folks who professionally deploy DMARC, they regularly use = p=3Dquarantine pct=3D0 as part of the deployment process. There are = DMARC failures that go undetected in a p=3Dnone situation but that is = detected in a p=3Dquarantine  pct=3D0 situation.  My = understanding was this was related to indirect flows through mailing = lists and how mailing lists are handling the header transformation but = it=E2=80=99s possible I got that piece incorrect. 

p=3Dquarantine is valuable for other reasons as = well, and I think it should be kept. 

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=_B6A33DFF-BD92-46DC-B9D0-42F5F07324FB-- From nobody Thu Dec 3 03:05: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 1A0BA3A005D for ; Thu, 3 Dec 2020 03:05:41 -0800 (PST) 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 R59CgIjhkcIH for ; Thu, 3 Dec 2020 03:05:39 -0800 (PST) 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 8FBE33A003E for ; Thu, 3 Dec 2020 03:05:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1606993537; bh=ua8+T2ZG4gOznVZ5U2DoXdy9DH/NRbkpJ9H5UYoEjFA=; l=716; h=To:References:From:Date:In-Reply-To; b=CjTIVjGZWhCJJZSiw15DwXIops+3AIsOJxtG50/mxw+2U6tnaJVF0EyRbR/uy3iN1 m4uWopivbvbVpXYyHeBUlfewRnXrbSz0tlxCEBu1R96PumU9ul56xAIvSlcL0Mbbc3 kuTliylwM1OiLhDYdErEm00oU3OWismzgeHhehpgG3G86EDeAsQI0utNo2LtL Authentication-Results: tana.it; auth=pass (details omitted) Original-From: Alessandro Vesely 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 00000000005DC0C4.000000005FC8C681.000062D5; Thu, 03 Dec 2020 12:05:37 +0100 To: dmarc@ietf.org References: <8c83fffc-077d-9ddb-db2f-b9763361c60f@tana.it> <39eafc5e-3d9c-0bea-1173-7277070195ea@wisc.edu> <081c42a3-492b-89b7-ad76-ccec48dea091@tana.it> <2d1dca4f-e46a-646c-9fa3-d9ca56c72196@tana.it> <127cca11-1fef-b75c-65ca-aa7119e295d5@baptiste-carvello.net> From: Alessandro Vesely Message-ID: <46eec266-0f16-b25b-4af4-863dfa3cf7d5@tana.it> Date: Thu, 3 Dec 2020 12:05:37 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: <127cca11-1fef-b75c-65ca-aa7119e295d5@baptiste-carvello.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] A policy for direct mail flows only, was ARC questions X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 03 Dec 2020 11:05:41 -0000 On Tue 01/Dec/2020 14:27:04 +0100 devel2020 wrote: > Le 01/12/2020 à 11:37, Alessandro Vesely a écrit : >> >> [...] a meagre set of old-fashioned individuals who still dislike mass social media [...] > > Can decisions please be made based on sound technical reasons rather > than intolerance and zealotry? That was not meant to prompt the making of any decision. It is a fact that mailing lists are not among the most popular communication tools. > Setting aside the form of your argument: no, contracting with Facebook > et al should not be a prerequisite for using the Internet for any > purpose. By the very definition of "open network". I agree with that "should". Best Ale -- From nobody Thu Dec 3 03:24:33 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FCB83A045E for ; Thu, 3 Dec 2020 03:24:32 -0800 (PST) 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 g6O-zDxJGCuL for ; Thu, 3 Dec 2020 03:24:30 -0800 (PST) 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 1B2B03A046A for ; Thu, 3 Dec 2020 03:24:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1606994668; bh=p7HKssRH2gJnPEJIUVz/sSaY4lXzmRArKNvODlk9iyI=; l=1053; h=To:References:From:Date:In-Reply-To; b=BJoSYzv+hMCek+IGEtWuoomMAY4RmyZhe43Li11fFMmS8wy2U4nfAROfqOTgLBMri 74XYwwhlWuWrMVhYT5BMinqKaWmddUjNyCQJ+k1CEoLI5WZy1XMQP0RL9yZVygH9gZ xlRjN7gRhwmqBxsQKQ5ClPWKzLmfX4Ll8N+qejYmvNg2jOgqCxUAvI54s+STZ Authentication-Results: tana.it; auth=pass (details omitted) Original-From: Alessandro Vesely 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 00000000005DC03D.000000005FC8CAEC.0000654C; Thu, 03 Dec 2020 12:24:28 +0100 To: dmarc@ietf.org References: From: Alessandro Vesely Message-ID: Date: Thu, 3 Dec 2020 12:24:28 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Discussion - ARC/Extensible Reporting (Ticket #56) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 03 Dec 2020 11:24:32 -0000 On Wed 02/Dec/2020 20:46:54 +0100 Brotman, Alex wrote: > > While this ticket/enhancement specifically mentions ARC, I could perhaps see the usefulness in other places. It seems like it would be more beneficial to create a method by which other documents could provide XML- based "extensions" to the report. This would allow mechanisms relying on DMARC to independently define their reporting schema to be included in DMARC aggregate reports. Alternately, we could focus specifically on ARC, and work to include that in the base XML. This means that any later reporting requirements could again require changes to the core drafts. > Another possibility is for ARC to define its own report format. Hijacking rua= targets to send a different kind of report should be allowed. Otherwise, we could define a new tag, e.g. rue= (e for Extension). In either case, as we're introduce variations in aggregate report content, we have to devise a method for determining what version/kind of report is attached to a given message. Best Ale -- From nobody Thu Dec 3 04:39: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 EF01C3A08BD for ; Thu, 3 Dec 2020 04:39:28 -0800 (PST) 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 TDDG5yyBonAy for ; Thu, 3 Dec 2020 04:39:27 -0800 (PST) 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 312C43A08B1 for ; Thu, 3 Dec 2020 04:39:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1606999165; bh=NsBCm+pQyLgq3Y+fYeYBpNqlExAI4wNO5pbIPyIVJWc=; l=899; h=To:References:From:Date:In-Reply-To; b=AKOKyWPZ2h96GAjstZBlQRUK51J6kf7IdHyGMPXbsLwHLGNFj/J/WnSx2z+2UY9st HVZ9k5th46GIsd08f6lknwA8cyzgUig3N23ShyGdGqMidp/yl+NP/Ac8yWSxXbVPUW daPjYH/C2IPpjZomb66+o1UuIU4JNa8VN59Jv/yJ/H70Pcpsh2m3poeAvy+Qb Authentication-Results: tana.it; auth=pass (details omitted) Original-From: Alessandro Vesely 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 00000000005DC02A.000000005FC8DC7D.00006EDA; Thu, 03 Dec 2020 13:39:25 +0100 To: John Levine , dmarc@ietf.org References: <20201202233432.D45FB28E1943@ary.qy> From: Alessandro Vesely Message-ID: Date: Thu, 3 Dec 2020 13:39:25 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: <20201202233432.D45FB28E1943@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] Ticket #42 - Expand DMARC reporting URI functionality X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 03 Dec 2020 12:39:29 -0000 On Thu 03/Dec/2020 00:34:32 +0100 John Levine wrote: > In article you write: >>A better means to control report size is to gauge the reporting interval. > > When this came up before someone said that reports can be extremely > large, many megabytes. An HTTP POST or PUT is a much better way to send that. However faster, an https PUT/POST at midnight arrives later than a mailto at midday. > Here's another nit: POST doesn't pass the report's filename. There > should be a copy of the name in the header of the gzip data, but > semantically it would be better to do an https PUT to > /. That also has the advantage of being idempotent so > if it puts the same file twice the server can tell it's a duplicate. Yes, PUT is better than POST. How about pgp-signing the file with the dkim key? Best Ale -- From nobody Thu Dec 3 04:57: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 2CBC73A091B for ; Thu, 3 Dec 2020 04:57:47 -0800 (PST) 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 U9PdanKlvUyO for ; Thu, 3 Dec 2020 04:57:45 -0800 (PST) Received: from mail-pl1-x62c.google.com (mail-pl1-x62c.google.com [IPv6:2607:f8b0:4864:20::62c]) (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 651D23A0913 for ; Thu, 3 Dec 2020 04:57:45 -0800 (PST) Received: by mail-pl1-x62c.google.com with SMTP id x4so1099369pln.8 for ; Thu, 03 Dec 2020 04:57:45 -0800 (PST) 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=uoN69lMK7Y0sceqpkNbuUOKfvV96WNUZJTCJiyWagkM=; b=ljj5Dqi5QYRy3G1dgI1mkX0/dzVumNIAkRYDIzIrInCVV0zN3eTnmNqST6R3bHPS78 yS8GWoKePckC33sC4iP6B6+oknaUAwvO3h8xJRi0Fkuv77E5nvPTffgqc35hMCwsWKF6 8EpJ9R/pZFujn21GVEp8sTTE2c6LIlEiOPRIzyWaMcFEHGYeSd2j+YTDq6vpqW0D7X0L S0kNUAmLfZhuJ2zocvZRg5/MOHSTEamOS7aUX89w+wEBXV5YBJg7I4Avt+YBtPAgXcWW doJiGFjN7IpH0uTSPE3ApTdAqD6Ib2oQl0E5JMon8Eb9vSGNmmbs6Ui8MiXmS5wYRzTU G6wA== 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=uoN69lMK7Y0sceqpkNbuUOKfvV96WNUZJTCJiyWagkM=; b=k5wyy//0lrB5lrdzzqV/jtAKs+bSEyk1EyjPloEKt/w5G9AzmjKRK1JlXQ9hJxv8FS clhauJho8w/d6u8X5KI9tOBQYTncLATdQ1/MnrZNfOcOQgNHSWQMPpBCEPDFdxElSQZt i5f+3afDq86qR+QnxwpaN8lXp+rGJoSPThUdHWKDJbpchLEbbeEovSiGwa2ifiH/yfm6 yGg5EB+vrGOSUDCk1RDFueSC8fdZ/ONc26QY810G9lFSEZCCLfYD6G1JOLvfJ40MMuZc unz6/fugRUUOHTsux3fhtNVWeWtUTmZh/6DOC72+pzuO7jZpnCxVW8xQejmq08P+r5n0 FaQA== X-Gm-Message-State: AOAM531flbOby4jfoBixo0IxFmpwZ/UDCLH1cB0cljDcY0qgMsfXgjYk PlfQFElCL4vgrbF/i/w1bmfHHw2Q37o= X-Google-Smtp-Source: ABdhPJwCUofarjQlXv6d51q7n+IJ2HnMtAX/bVW0+ZMN2RusY0erh6FEwDMsbzGQeX4qKh6fwOQT6w== X-Received: by 2002:a17:90a:db48:: with SMTP id u8mr2927286pjx.81.1607000264436; Thu, 03 Dec 2020 04:57:44 -0800 (PST) Received: from [192.168.0.109] (c-24-130-62-181.hsd1.ca.comcast.net. [24.130.62.181]) by smtp.gmail.com with ESMTPSA id o198sm1877369pfg.102.2020.12.03.04.57.43 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 03 Dec 2020 04:57:43 -0800 (PST) To: Jim Fenton Cc: dmarc@ietf.org References: <20201202021651.E8EE128C576A@ary.qy> <327860af-2fa7-63ee-4b89-6e7e383f3d53@crash.com> <2804da89-84d1-f601-9425-0b0d9baf6ae1@gmail.com> <1f6cae74-4eed-47f5-7249-e526bf1f5845@crash.com> From: Dave Crocker Message-ID: <5d5c2409-7d81-2c2f-a1e7-4add06a0f5a7@gmail.com> Date: Thu, 3 Dec 2020 04:57:43 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------7D36546FD1A6C76A1B8F1306" Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] Ticket #39 - remove p=quarantine X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 03 Dec 2020 12:57:47 -0000 This is a multi-part message in MIME format. --------------7D36546FD1A6C76A1B8F1306 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 12/2/2020 10:12 PM, Jim Fenton wrote: > The problem is that /quarantine/ and /reject/ are imperative verbs. As I said, I suspect that changing the vocabulary is not operationally practical  at this point.  It would be great for the folk already using DMARC to state a willingness to employ alternative vocabulary; but I'm not expecting them to. If we get feedback to the contrary, we can have a vocabulary debate.  My own advice would be to avoid vocabulary that is directive about disposition and more declarative about status. d/ -- Dave Crocker dcrocker@gmail.com 408.329.0791 Volunteer, Silicon Valley Chapter American Red Cross dave.crocker2@redcross.org --------------7D36546FD1A6C76A1B8F1306 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 12/2/2020 10:12 PM, Jim Fenton wrote:
The problem is that quarantine and reject are imperative verbs.

As I said, I suspect that changing the vocabulary is not operationally practical  at this point.  It would be great for the folk already using DMARC to state a willingness to employ alternative vocabulary; but I'm not expecting them to.

If we get feedback to the contrary, we can have a vocabulary debate.  My own advice would be to avoid vocabulary that is directive about disposition and more declarative about status.

d/

-- 
Dave Crocker
dcrocker@gmail.com
408.329.0791

Volunteer, Silicon Valley Chapter
American Red Cross
dave.crocker2@redcross.org
--------------7D36546FD1A6C76A1B8F1306-- From nobody Thu Dec 3 06:22: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 DE2843A0F02 for ; Thu, 3 Dec 2020 06:22:10 -0800 (PST) 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 M8LF6x57Bn34 for ; Thu, 3 Dec 2020 06:22:08 -0800 (PST) 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 925A03A0F0A for ; Thu, 3 Dec 2020 06:22:01 -0800 (PST) Received: by mail-qv1-xf2e.google.com with SMTP id 4so992996qvh.1 for ; Thu, 03 Dec 2020 06:22:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=bY5rbHZIrkF1UsCqxMA9KgmHhKFkcK77ZUVvIoqVXYA=; b=MeObyLkKhEU0eJSPmCWpU3l4aIrv2h4xrIemE7VYxCDyxERQ2hwS7AqgAXveDt46uV hic3HiiKKCocay7kQVetikROXP/15SU+PY7rooKeis05nN42gjQdt2T9OwMpmqH9shAE 5QlRd9NwKVhe7tfKBHvrDZIKSs/4ysOj/9FZoZhtC8sHORDFpWPmg38+pV1+mBjklkEs +XR/MgjMAu1mQXdZAZZ/AtmQ19L9wG9jhN5Fyl8+sXCA6AKxzkggDO+JDQ4god2NoLAH qW4QzbjXQ55bGtmQlO8Mt9KXwcYYBD+189OY2z8K4VvyOZzP5B5G8QzlPTXj4S9kmKty B3KQ== 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=bY5rbHZIrkF1UsCqxMA9KgmHhKFkcK77ZUVvIoqVXYA=; b=PNrEo7nXR3blynJwhYLxznfnbiPvLPW9gF8rwjbGWzrFpY3841FX8JKJtH9GwKVA1T Dnso/N5GXubxTNZ5pRSHEPluA65aj/0OieY67Ry7KJGxTRhmFbQI+Zyk7+tLG2Q0zYMq QbIyhHZx6S2iOr4tXTjxLw18TPuht29LbvTOi5NVdNDVCzXqTgB8vs7XjP4kWAKyz0wK WqBgPnxn17xOQ8KWGBG6ImMroHDFORzKMflktzBjcpRBCbDtHDZfLIjiJHivDnmunDPg d0HKWna05BXPHv928XWGLqg1sbO8dEWg61hYmtiU7MrHboCEpA2gnnVZjMM77BwAK6c3 eHUQ== X-Gm-Message-State: AOAM530JIhqF65rjMNaFCA52gHKP6LFUMlu+6hkt2LtneO6VdF3LijsE oVXZV7+Y4+1C/axm1LtSIaKU+lxWKAoIgTzLJkilcSQBZ+I= X-Google-Smtp-Source: ABdhPJzDomNdQonzYXduegcNYZA7DW4HOsIt5o2haI/3pWJ7fmapLYxnEsBlp2TlX+xQnfFo7layM7v+JQ+2TMsDvbE= X-Received: by 2002:a0c:db11:: with SMTP id d17mr3259451qvk.39.1607005320323; Thu, 03 Dec 2020 06:22:00 -0800 (PST) MIME-Version: 1.0 References: <5C559553-3F45-494D-9714-F7BC47BB82FF@wordtothewise.com> <2F1BED43-5AE5-42BC-AA45-67C5FDAF6CB8@wordtothewise.com> In-Reply-To: <2F1BED43-5AE5-42BC-AA45-67C5FDAF6CB8@wordtothewise.com> From: Todd Herr Date: Thu, 3 Dec 2020 09:21:44 -0500 Message-ID: To: IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000453ccd05b59015e0" Archived-At: Subject: Re: [dmarc-ietf] Ticket #39 - remove p=quarantine X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 03 Dec 2020 14:22:18 -0000 --000000000000453ccd05b59015e0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Dec 3, 2020 at 4:28 AM Laura Atkins wrote= : > > > On 3 Dec 2020, at 06:03, Jim Fenton wrote: > > On 2 Dec 2020, at 1:47, Laura Atkins wrote: > > p=3Dquarantine is quite useful, particularly for those folks who are tryi= ng > to get to a p=3Dreject state. > > In practice, senders who publish p=3Dnone don=E2=80=99t find all of the i= ndirect > mail flows as some mailing lists do nothing to transform the 5322.from > address for a p=3Dnone policy. Senders have found that when they switch f= rom > p=3Dnone to p=3Dquarantine pct=3D0 they regularly find mail that was not = failing > for a p=3Dnone. > > > I=E2=80=99m really confused by this. It sounds like the 5322.from address > rewriting is creating additional errors that didn=E2=80=99t exist beforeh= and, and > that=E2=80=99s the opposite of the intended purpose. Isn=E2=80=99t the pu= rpose of rewriting > the 5322.from address to change the domain to that of the mediator, which > should redirect reporting to the mediator rather than the original sender= ? > > > What I am trying to say is that as I understand it from the folks who > professionally deploy DMARC, they regularly use p=3Dquarantine pct=3D0 as= part > of the deployment process. There are DMARC failures that go undetected in= a > p=3Dnone situation but that is detected in a p=3Dquarantine pct=3D0 situ= ation. > My understanding was this was related to indirect flows through mailing > lists and how mailing lists are handling the header transformation but it= =E2=80=99s > possible I got that piece incorrect. > > Time was (and may still be) that there was a very specific type of mailing list for which p=3Dquarantine, pct=3D0 was required to get accurate DMARC reporting, and that was for mail that transited Google groups. There've been a couple of public discussions of the topic over on mailop, including a thread from April 2018 with the subject of "DMARC p=3Dquarantine pct=3D0"= . --=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. --000000000000453ccd05b59015e0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Dec 3, 2020 at 4:28 AM Laura Atki= ns <laura@wordtothewise.com> wrote:



On 2 Dec 2020, at 1:47, Laura At= kins wrote:

p=3Dquarantine is quite useful= , particularly for those folks who are trying to get to a p=3Dreject state.=

In practice, senders who publish p=3Dnone don=E2=80=99t find all of= the indirect mail flows as some mailing lists do nothing to transform the = 5322.from address for a p=3Dnone policy. Senders have found that when they = switch from p=3Dnone to p=3Dquarantine pct=3D0 they regularly find mail tha= t was not failing for a p=3Dnone.

I=E2=80=99m really co= nfused by this. It sounds like the 5322.from address rewriting is creating = additional errors that didn=E2=80=99t exist beforehand, and that=E2=80=99s = the opposite of the intended purpose. Isn=E2=80=99t the purpose of rewritin= g the 5322.from address to change the domain to that of the mediator, which= should redirect reporting to the mediator rather than the original sender?=

What I am trying to say is= that as I understand it from the folks who professionally deploy DMARC, th= ey regularly use p=3Dquarantine pct=3D0 as part of the deployment process. = There are DMARC failures that go undetected in a p=3Dnone situation but tha= t is detected in a p=3Dquarantine =C2=A0pct=3D0 situation.=C2=A0 My underst= anding was this was related to indirect flows through mailing lists and how= mailing lists are handling the header transformation but it=E2=80=99s poss= ible I got that piece incorrect.=C2=A0


Time was (and may still be) that there was a v= ery specific type of mailing list for which p=3Dquarantine, pct=3D0 was req= uired to get accurate DMARC reporting, and that was for mail that transited= Google groups. There've been a couple of public discussions of the top= ic over on mailop, including a thread from April 2018 with the subject of &= quot;DMARC p=3Dquarantine pct=3D0".=C2=A0


--

Todd Herr | Sr. Technical Program Manager
p: 703.220.4153


This email and all data transmitted with it contain= s confidential and/or proprietary information intended solely for the use o= f individual(s) authorized to receive it. If you are not an intended and au= thorized recipient you are hereby notified of any use, disclosure, copying = or distribution of the information included in this transmission is prohibi= ted and may be unlawful. Please immediately notify the sender by replying t= o this email and then delete it from your system.

<= /div>
--000000000000453ccd05b59015e0-- From nobody Thu Dec 3 09: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 E84EC3A0930 for ; Thu, 3 Dec 2020 09:08:54 -0800 (PST) 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 (2048-bit key) header.d=iecc.com header.b=bflQ/To+; dkim=pass (2048-bit key) header.d=taugh.com header.b=KSi+n202 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T8tiHXaM2_zh for ; Thu, 3 Dec 2020 09:08:53 -0800 (PST) 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 DBEEC3A091B for ; Thu, 3 Dec 2020 09:08:52 -0800 (PST) Received: (qmail 32437 invoked from network); 3 Dec 2020 17:08:51 -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=7eb3.5fc91ba3.k2012; i=johnl-iecc.com@submit.iecc.com; bh=7/39eEJHegg2+YG5gXi5ZLaAobSej4fgelAEblJXc1g=; b=bflQ/To+A17D05zU45iq+5V0GGUIyPb8drnp/hBvH0eAcp/WytcE8GiBcx1+IpesNlisWiNVCFHmPazzf0IXM6mcSCOxsgYTJwmYK3wn8DiCLZKwULlVhEZn3zL2OINX20ralswY2yp/LATK0/ZAbB5nkZjDwSnLjM9fS8Kk5fQ1LIbmLcBp/HRCnM5sxPCXT7XVrMkN9I4GqKl0bzmWhsveoKT5tjF1a7E6sLT2wLaUlAmwv+mc0yW0nXinN2nIDkzMoCsM8NY65O+9evFRxRVkwUMm4B8B4M8NVIrHCVV9cWxfP/5xid5XBy2P6+7Z/Lqmpf2mi5BTZ/t0RbRLNA== 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=7eb3.5fc91ba3.k2012; olt=johnl-iecc.com@submit.iecc.com; bh=7/39eEJHegg2+YG5gXi5ZLaAobSej4fgelAEblJXc1g=; b=KSi+n202Zl4JGj1oabSWfQcB2RQ+e1/EzS2X6QOgEVkZDbp5gizd0g+b/8113ClXpHClqhHBlSFzPMc4P9/vm+5/thn7qIDscc0ocRj35tbCGd85pw0mPIP/2ykg/QCGwYLoq/SQcZRy71GBOO0YXvoU4/FoBbi5MA4xn0mblslwLAaXPpx2tVhI5g4PpzTpOXRhTBPDu9foFh1xO/IFLurbd6T/3mZS7Fp8bShiE6luSVRcLmBLPcvyrL4zXh+H1dhIy5xwpAwe9TAlfr0rQne/SdCyz0YyA3/2ymDluAY7RZm7QRA/Gb3NFuNrceas5PS/IirJlfpSvFs6vyK+Wg== 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; 03 Dec 2020 17:08:50 -0000 Date: 3 Dec 2020 12:08:50 -0500 Message-ID: <479cfb50-b98e-fbbe-e7ce-375557cd624@taugh.com> From: "John R Levine" To: "Alessandro Vesely" , dmarc@ietf.org In-Reply-To: References: <20201202233432.D45FB28E1943@ary.qy> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [dmarc-ietf] Ticket #42 - Expand DMARC reporting URI functionality X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 03 Dec 2020 17:08:55 -0000 >> When this came up before someone said that reports can be extremely >> large, many megabytes. An HTTP POST or PUT is a much better way to send >> that. > > However faster, an https PUT/POST at midnight arrives later than a mailto at > midday. I'm sorry but this makes no sense at all. Why do you believe that people would not send reports by mail and by https at the same time? > Yes, PUT is better than POST. > > How about pgp-signing the file with the dkim key? Sorry, that doesn't make any sense either. DKIM keys and PGP keys are different. It is hypothetically possible to sign an http transaction with DKIM but that would be a giant distraction from what we're doing here. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From nobody Thu Dec 3 09:46: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 E08543A0A26 for ; Thu, 3 Dec 2020 09:46:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.65 X-Spam-Level: X-Spam-Status: No, score=-1.65 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, 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=mtcc-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MW3EgRXLTAM6 for ; Thu, 3 Dec 2020 09:46:16 -0800 (PST) Received: from mail-pj1-x102b.google.com (mail-pj1-x102b.google.com [IPv6:2607:f8b0:4864:20::102b]) (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 62FC93A09BE for ; Thu, 3 Dec 2020 09:46:16 -0800 (PST) Received: by mail-pj1-x102b.google.com with SMTP id f14so1492356pju.4 for ; Thu, 03 Dec 2020 09:46:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mtcc-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=6wt4fhnEFggxLtTqKY3LcgdX5Ixwv4CTu461jT6Q1m0=; b=DEQcDRFsgVNO4KQUPTyTGToIoiEW83I6xK73zp2El9NOSsvkfWiL/qoOeKFAwFlJim BRrRS3aCUyZflyjJcff1ggt97rriNOZSa0hwKmJfyfs/1Bd2G5YwELtJo0NlRrsAM0Kd 6277NzNoIqrOZ60kz+WHdxyzIl3NLSrRPcdKbPeZR5Rn+03OFVuGkR54m4Zt0xlQhekm kjNUPZkFWomxy7goO1BeQL0Nu2Ke9N2JNy9epXifnOrTmBw8+q58qMbmRPALbWjeQYut E7aOj9WBponOARfHDpdg3iYBBLgtZj0eSIGqXAejXZPdo7AEkcUKNHcxV3B+kvfmYky9 Q4DA== 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=6wt4fhnEFggxLtTqKY3LcgdX5Ixwv4CTu461jT6Q1m0=; b=hPGREm7rP0tXW3O6c9IFNQuKSkH91qL0l4ji5UTmWBjZguk9i3ZrzkftoxpH7ncsIS Yb2DXcLcEEc72zmOUBHJk2LtpMGL86eyMVjymEPwoRWaESjOWAZ63qFA8nq0f2yItuPJ eS4/7NoPGZH7gI73xMhQkyumdSnUuWlB04Y819NxH7LM4ElMXqbTEbN6MpdYPQ4SCGSC puV+g/TBfypHD7hpt535zN53G8hsVN8zmKPn1hW2ogEO91GvHp31WL3TNhQoWwrNsVYC vHT4AFrf7gRK7Jj8vgua2cpA3LVqIXh5i5/cWBx+7VI988T8aSzclQ/9CTd8V7pyHQut p8vQ== X-Gm-Message-State: AOAM530TfO9A2e3xvHTJxbm0a+IAM+QtsXh8qKm7cstEVXSPS8uB0zcJ YCUoVanVaokGovQhsX1zorS1Nk3u2lyDNA== X-Google-Smtp-Source: ABdhPJxjpzNG/m4amQFeYBaMQpDWoGpyl0SRtKsvzh8+QBSX0wgMiEjeBGC6bh7XfGXCDSCd0xKpgA== X-Received: by 2002:a17:90a:a50b:: with SMTP id a11mr237300pjq.170.1607017575205; Thu, 03 Dec 2020 09:46:15 -0800 (PST) Received: from mike-mac.lan (107-182-42-33.volcanocom.com. [107.182.42.33]) by smtp.gmail.com with ESMTPSA id k4sm2407927pfa.103.2020.12.03.09.46.13 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 03 Dec 2020 09:46:14 -0800 (PST) To: dmarc@ietf.org References: <20201202021651.E8EE128C576A@ary.qy> <327860af-2fa7-63ee-4b89-6e7e383f3d53@crash.com> <2804da89-84d1-f601-9425-0b0d9baf6ae1@gmail.com> <1f6cae74-4eed-47f5-7249-e526bf1f5845@crash.com> From: Michael Thomas Message-ID: Date: Thu, 3 Dec 2020 09:46:13 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------916DED4142513BE05255A22C" Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] Ticket #39 - remove p=quarantine X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 03 Dec 2020 17:46:18 -0000 This is a multi-part message in MIME format. --------------916DED4142513BE05255A22C Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 12/2/20 10:12 PM, Jim Fenton wrote: > > On 2 Dec 2020, at 6:09, Dave Crocker wrote: > > *none*: The Domain Owner offers no expression of concern. > > *quarantine:* The Domain Owner considers such mail to be > suspicious. It is possible the mail is valid, although the > failure creates a significant concern. > > *reject: *The Domain Owner considers all such failures to be a > clear indication that the use of the domain name is not valid. > See Section 10.3 > > for some > discussion of SMTP rejection methods and their implications. > > The problem is that /quarantine/ and /reject/ are imperative verbs. > The specification can use any definition, but if it uses imperative > words, they are going to be taken as imperative. > > Maybe /discardable/ should be used instead. > If it's not clear that it's "this is what I'd do" rather than some requirements language imperative then maybe that could be made more clear. > Why do I have a feeling of deja vu? > > No comment. Mike --------------916DED4142513BE05255A22C Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit


On 12/2/20 10:12 PM, Jim Fenton wrote:

On 2 Dec 2020, at 6:09, Dave Crocker wrote:

*none*: The Domain Owner offers no expression of concern.

*quarantine:* The Domain Owner considers such mail to be
suspicious. It is possible the mail is valid, although the
failure creates a significant concern.

*reject: *The Domain Owner considers all such failures to be a
clear indication that the use of the domain name is not valid. 
See Section 10.3
<https://tools.ietf.org/html/rfc7489#section-10.3> for some
discussion of SMTP rejection methods and their implications.

The problem is that quarantine and reject are imperative verbs. The specification can use any definition, but if it uses imperative words, they are going to be taken as imperative.

Maybe discardable should be used instead.

If it's not clear that it's "this is what I'd do" rather than some requirements language imperative then maybe that could be made more clear.


Why do I have a feeling of deja vu?


No comment.

Mike

--------------916DED4142513BE05255A22C-- From nobody Thu Dec 3 10:11: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 E35613A0B2B for ; Thu, 3 Dec 2020 10:11:36 -0800 (PST) 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 wI-xDK91KsTu for ; Thu, 3 Dec 2020 10:11:35 -0800 (PST) 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 20CDB3A0B04 for ; Thu, 3 Dec 2020 10:11:34 -0800 (PST) Received: from localhost.junc.eu (localhost.junc.eu [127.0.0.1]) by mx.junc.eu (Postfix) with SMTP id 919628074D for ; Thu, 3 Dec 2020 18:11:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junc.eu; i=@junc.eu; l=341; q=dns/txt; s=default; t=1607019091; h=from : subject : date : to; bh=TgS6+Joaf2tM/9bcZr7NL0I5vKGF/+U2kZLOvqlOYbA=; b=XDmZHTsxWQdkcnHTWnuvo/qs9R83Ca+U/j9SAeQOmKdKbO0zhM8fm/1zm0MJbLBoXWor5 P06Mtj50vxE/iXwmiUOZXw61MoEFUroJLOwBLmw+E4joTGA4sr5JVlUvEPDuYzj5A2lHm1f eIl5PK//OmE9GLi2iDY3TxhnD6O++rk= Received: from localhost.junc.eu (localhost.junc.eu [IPv6:::1]) by mx.junc.eu (Postfix) with ESMTPSA id 755E880341 for ; Thu, 3 Dec 2020 18:11:31 +0000 (UTC) MIME-Version: 1.0 Date: Thu, 03 Dec 2020 19:11:31 +0100 From: Benny Pedersen To: dmarc@ietf.org In-Reply-To: <162586f5-d565-0e4f-955d-8ceca1d569d2@mtcc.com> References: <20201124020453.AFDC027CE5C8@ary.qy> <1eed8278-4efa-4abc-15e0-2efcf014e82e@mtcc.com> <446d491b-100a-9813-6463-2294f67bbda7@mtcc.com> <4190de2d-9f17-06d5-6354-30c989eecd4a@mtcc.com> <17d886fd-49fd-28d8-f8e4-7caf2e85919c@taugh.com> <8bc3c7ad-2a42-3eed-524c-8c50b16131c2@mtcc.com> <42178950-1ac3-27b4-a981-155fd9117969@taugh.com> <70bd5e9-f0e8-3bdf-c5f0-6428841e1577@iecc.com> <162586f5-d565-0e4f-955d-8ceca1d569d2@mtcc.com> User-Agent: Roundcube Webmail/1.4.8 Message-ID: <125a8014168264de8b7de9488eb3058d@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] ARC questions X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 03 Dec 2020 18:11:37 -0000 Michael Thomas skrev den 2020-12-03 03:58: > if you're trying to make a point about the bloat, you might actually > get your facts straight. ARC adds an additional DKIM signature and a > Seal. i have no idea what a X-Google-DKIM-Signature is and is not > relevant. would you show an example on that openARC adds openDKIM signature ? From nobody Thu Dec 3 10:55: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 4F6B53A064B for ; Thu, 3 Dec 2020 10:55:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5bhWBZsahAvs for ; Thu, 3 Dec 2020 10:55:03 -0800 (PST) Received: from mx0b-00143702.pphosted.com (mx0b-00143702.pphosted.com [148.163.141.77]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19A153A064A for ; Thu, 3 Dec 2020 10:55:02 -0800 (PST) Received: from pps.filterd (m0156894.ppops.net [127.0.0.1]) by mx0b-00143702.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 0B3IdNLV004260; Thu, 3 Dec 2020 13:55:02 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=20190412; bh=2GUC1Gkz0Y+TLwXcp2zKSWDnedDpBm4v+gfastn+qsg=; b=lXujgIl5AujjWrr/kNYZa5jvNyH3mdizHKIlCo53oZZa1kjle9/eqP+h4dzBP4UX3qCo mSWTAyF7xeJM6JKYjEiQKEk63IUlte5O/H9bW2KIsOanhulZxW8qAe2fASmcWcjSl+z0 DvH/sxwRu2ppnJX7Yokp2u0RnDlfGTG0qf+P3uwz7Nyj5oNpVVE3pHSz+7z5KyQoi8Pf b8VvCFnyq4weJpEQitdzyEh0cmiQPYPgi+NqH28lzhxNnP1ZU6rf8+WBDI7XjQ5SXI8S lAcArTbD6tt1bLPWYB5Awzcx9P/DtkwS8xy3XxLd1OpNfubewGX34l1awZGG2QkkJcXz PQ== Received: from pacdcex45.cable.comcast.com (dlppfpt-wc-1p.slb.comcast.com [96.99.226.136]) by mx0b-00143702.pphosted.com with ESMTP id 353m9x3bfn-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 03 Dec 2020 13:55:02 -0500 Received: from PACDCEX41.cable.comcast.com (24.40.2.140) by pacdcex45.cable.comcast.com (24.40.2.144) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 3 Dec 2020 13:55:00 -0500 Received: from PACDCEXEDGE01.cable.comcast.com (76.96.78.71) by PACDCEX41.cable.comcast.com (24.40.2.140) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Thu, 3 Dec 2020 13:55:00 -0500 Received: from NAM10-BN7-obe.outbound.protection.outlook.com (104.47.70.108) by webmail.comcast.com (76.96.78.71) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 3 Dec 2020 13:54:52 -0500 Received: from MN2PR11MB4351.namprd11.prod.outlook.com (2603:10b6:208:193::31) by BL0PR11MB3123.namprd11.prod.outlook.com (2603:10b6:208:7b::33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3632.17; Thu, 3 Dec 2020 18:54:51 +0000 Received: from MN2PR11MB4351.namprd11.prod.outlook.com ([fe80::7ca6:b482:a6b0:4d42]) by MN2PR11MB4351.namprd11.prod.outlook.com ([fe80::7ca6:b482:a6b0:4d42%7]) with mapi id 15.20.3632.021; Thu, 3 Dec 2020 18:54:51 +0000 From: "Brotman, Alex" To: Alessandro Vesely , "dmarc@ietf.org" Thread-Topic: [dmarc-ietf] Discussion - ARC/Extensible Reporting (Ticket #56) Thread-Index: AdbI4+CbIMDOrFacSCuqUWajtLQ8TwAgvwMAAA97pBA= Date: Thu, 3 Dec 2020 18:54:51 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: tana.it; dkim=none (message not signed) header.d=none;tana.it; dmarc=none action=none header.from=comcast.com; x-originating-ip: [2601:43:101:380:606a:cfa1:23b2:7ac8] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 983b6dc2-647e-48a1-1082-08d897bcea46 x-ms-traffictypediagnostic: BL0PR11MB3123: 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: vQrUSQoU1CQN3ZTMsjxbRt/L5KVwP5QQvMiQf2AkYpGCPWhht8djFWTLus9qn+WetQ6R7tkdP+lGhNvqAr36bU8EstgOhBAMCLgC2dKQ2M3kGY7r5MbgqaIKAPqptL6IUiHVqIMnf2hoXoVMfczpzaQOya1wItf259g12PUyYTWGkvi60X0ONpepDKqZmzR5Y5LXsLe0tMY+0HGuXqFsgWXBIlPSqEWTl0aZEj4IL0qhATWZ03GXnU4wjMbun9xLrytajMRhlhIoVPXrhnzOVxGg148Od1VYsWqpIYlmhulriw+RDsW3hz7aNXg5XoVvwGtBW9BOwhAsBoEzq7D5Rg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR11MB4351.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(39860400002)(366004)(346002)(376002)(396003)(136003)(8936002)(53546011)(9686003)(6506007)(8676002)(83380400001)(55016002)(478600001)(52536014)(316002)(110136005)(2906002)(7696005)(33656002)(71200400001)(186003)(5660300002)(86362001)(76116006)(66476007)(64756008)(66556008)(66946007)(66446008); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: =?us-ascii?Q?PvD5FuHQroictxyesFsvLYyMJIBOAo8FPVvcn9VAzAKKYU22TeCtNv3ZdJRy?= =?us-ascii?Q?5xfrp/6xupTO5NXVCjUK6o7Y7HBicU9XTwKR1P29oSp8hDTeydwP4akJ/Ff6?= =?us-ascii?Q?K2KYLJ9aHoQMbk+bh5sDbyf818eCCxUFE8iOwrnZIPae9CS6ik1ufUIQyyGT?= =?us-ascii?Q?hoiNbS9IyFRu+fy7LjEU/ElnDp+ciPr81afIabOdlQZ/fLh9iWxBQPVFcJf0?= =?us-ascii?Q?Blsl5m64rq0OYZBM6Zxx9dmdnLB89swJPQ86BQPU44Kp5qF0IMUq60XG7uII?= =?us-ascii?Q?h9bL/WjXgS2QOg4Y2pEc55k0sp6PmyI7ZPplKiBSu1DBrLjqq4nXhISmCUtP?= =?us-ascii?Q?ke/6A2tCy1d3qKAyMTULn3debZnae3KN6FdPVbB7MteJ+9OQbNkjPj/GjIuK?= =?us-ascii?Q?le/LEUHD7VPAHCtabS1NB7nhu73QIUSNOiK/fGssYu10ZsHFtqtU7sZmqvaW?= =?us-ascii?Q?H6Npbnk0eCDY/1jtZN1tQLyHy4GCRu4dMVJyg+ajE1tPhepMH0Yb1vbHeX5a?= =?us-ascii?Q?5bZs5p8L2XGYh7Z2HoeWei8eGseRwUeYLBtN+WDltZYtcI4VfMVH/ZS5pCGr?= =?us-ascii?Q?zv5LNZBehWRZzWggh4xgJ5YfGvwZJZ4dzmnu5SzkDxbKueMjYUbpRwzeYiZB?= =?us-ascii?Q?CuvQ88urn/DBhfEMEMHroNpQqNu8QJFR3FUVZ58BtE4MLgJTgIHxZUm1H4Fp?= =?us-ascii?Q?k+kacRuLx408DgHnYz9rszrRbmLoYSXrVgZXQqtfZ3DxT/JJG0Ha5XN8BT9a?= =?us-ascii?Q?0PpUQ4+W4HCxqLZgj/PAa5Mc8VcVTOZG/EZPibf/+xQOA34BNmmKczmjatE8?= =?us-ascii?Q?AL2LD63pCQdP4SUDsXPz7eptAmbR3ot0eXdLxW2yRjXuq5p0U5xyjev+BFGs?= =?us-ascii?Q?1LY58cDESrPtAxQ2jBzbSelBfogB7aAjqj9HKDrCNwVGud7uhz0ZWUhL1v7a?= =?us-ascii?Q?58H6p2DcwD4Ta72LnSKh+qagdvKijdTBfxFVkarJ4JI3hL5XxGuFQo1Y5buS?= =?us-ascii?Q?zdyZb/oBW3ecSBU9o3t6l0w5q5nvwsiKFoEE/8wHyBf0FgM=3D?= x-ms-exchange-transport-forked: True arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=LCLkP/80vdNjJl3UjzE1pqoNHOHssuESBbFFBGei0vir1d4zXqruHFwa7Q09Dg5y3iRGEnX5abZXtAnbsJnFP1UQEeSZxvi3jsqMMezx6KF7triiiQO8GOwR15XYx1OR4wgY2MJxBm65Jtzeq85WiJaystdNyu8xQUCWqWVI71PZdnhsqAifaAM3W69TNPkzeUWcafBHKE3E84Z5rzjSPiUBiji9Z0nBxJZiCQbUBLUwmEOse0rY21oOempyklR5Mx4GsnTB0a8IV/BCmLr7fqeL79o5h8pp00QA35uWzTDxmpIlFXmYDZ3rTbJGGsJ4gIA/l2BpI5xiRrb5nYxNaA== 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=ZWUuqwLI7K4FVUnqsOX2aS9ow6Dg7xK25J5asYnqW4E=; b=GgA7e9JPoS8h6So3npNteGZl/P1dVnhoSpBhA73H4fdwQ4YAvPJcBmdPok3IXvG943iPa6saFsn1mSoTBb7b5F+6KfBvBKZoiQYSB+vE5Mb67TWK4yrTfRIe/+t0wcWiqY6RKI1OFxXJeREqsG6MmkOn11qEeyrXyJDlvBTtgnipaffon8RLbDgPMsaFzX8beXznbVf4CB2CceCmbi3Ng8JhdY1D5Elr2IEb+dYPsaeKyhH29TZ4RaORLAC9mVP/JBabTZwTVNyYoRzVYx2V34xHtfeMl/Df+9SoXMWAe67b++TYN9dqUEJ1DrIU2DCAFXVABoKzfwoEq5tUrjSIxA== arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=comcast.com; dmarc=pass action=none header.from=comcast.com; dkim=pass header.d=comcast.com; arc=none x-ms-exchange-crosstenant-authas: Internal x-ms-exchange-crosstenant-authsource: MN2PR11MB4351.namprd11.prod.outlook.com x-ms-exchange-crosstenant-network-message-id: 983b6dc2-647e-48a1-1082-08d897bcea46 x-ms-exchange-crosstenant-originalarrivaltime: 03 Dec 2020 18:54:51.1242 (UTC) x-ms-exchange-crosstenant-fromentityheader: Hosted x-ms-exchange-crosstenant-id: 906aefe9-76a7-4f65-b82d-5ec20775d5aa x-ms-exchange-crosstenant-mailboxtype: HOSTED x-ms-exchange-crosstenant-userprincipalname: k8Qol+SDG+SzvqLTUEQGwT1puPmDxlZrzX4wHf/2qwxFOQRrCVXRNaM1N4pRdylhRjr3FtVdprXsauNeQ5CQGP9OOTNVW8ggDIrTtY131X0= x-ms-exchange-transport-crosstenantheadersstamped: BL0PR11MB3123 x-originatororg: comcast.com Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Forward AAETWS X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.312, 18.0.737 definitions=2020-12-03_11:2020-12-03, 2020-12-03 signatures=0 X-Proofpoint-Spam-Reason: safe Archived-At: Subject: Re: [dmarc-ietf] Discussion - ARC/Extensible Reporting (Ticket #56) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 03 Dec 2020 18:55:05 -0000 > -----Original Message----- > From: dmarc On Behalf Of Alessandro Vesely > Sent: Thursday, December 3, 2020 6:24 AM > To: dmarc@ietf.org > Subject: Re: [dmarc-ietf] Discussion - ARC/Extensible Reporting (Ticket #= 56) > > On Wed 02/Dec/2020 20:46:54 +0100 Brotman, Alex wrote: > > > > While this ticket/enhancement specifically mentions ARC, I could perhap= s > see the usefulness in other places. It seems like it would be more benef= icial > to create a method by which other documents could provide XML- based > "extensions" to the report. This would allow mechanisms relying on DMARC > to independently define their reporting schema to be included in DMARC > aggregate reports. Alternately, we could focus specifically on ARC, and = work > to include that in the base XML. This means that any later reporting > requirements could again require changes to the core drafts. > > > > > Another possibility is for ARC to define its own report format. Hijackin= g rua=3D > targets to send a different kind of report should be allowed. Otherwise,= we > could define a new tag, e.g. rue=3D (e for Extension). > > In either case, as we're introduce variations in aggregate report content= , we > have to devise a method for determining what version/kind of report is > attached to a given message. > We could add an element called "", and we allow ARC or whatever= it may be to exist under that element. The Aggregate Reporting document n= eeds to specify that any extensions are expected to be proper XML, and if t= here are no extensions, an empty element is sufficient. We could create a = bit more structure as a requirement if we wanted: ... (as defined in referenced standard) If a report parser doesn't know what ARC is (or any of the extensions), it = could skip the processing. I do understand this means that el= ement may break existing parsers, even when empty, though, I expect many of= the things we're proposing may fracture the expected XML. From nobody Thu Dec 3 11:11: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 B93EA3A07B3 for ; Thu, 3 Dec 2020 11:11:22 -0800 (PST) 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_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (4096-bit key) header.d=aegee.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iE4bjEZ7d2O0 for ; Thu, 3 Dec 2020 11:11:20 -0800 (PST) Received: from mail.aegee.org (mail.aegee.org [144.76.142.78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 55EEE3A074B for ; Thu, 3 Dec 2020 11:11:19 -0800 (PST) Authentication-Results: mail.aegee.org/0B3JAtBQ3175681; auth=pass (LOGIN) smtp.auth=didopalauzov@aegee.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=aegee.org; s=k4096; t=1607022676; i=dkim+MSA-tls@aegee.org; bh=JIS1rtHHpYfx9EuisOB168LQiUYvJJ5JdcNeJXC0TQE=; h=Subject:From:To:Date:In-Reply-To:References; b=qDSXLgUISDWEUL2+8V3aLC44MG4dAOPltfs0skt9XZ3pzb6KzZS7Y0+BC/Ic0Kiew RBXLenq+UJUd6p8a6zzy3NmhBYi6h3FdZE0Ug19/G1rxwHZEbZ78MDbMKf5O58a8eD eWjEXJpzs54nlCJQkclt3y7hbxX4+PMrmEj+Z3nBL5dU+L5AC487Sy25RsnVXWpJs+ ZMcpRKFIEOWsN8HU69exSo63CBTG+Qp6GXz+vc6SYGKIqLQxNviDTmyHhPiYIcPPfy gSqLwCgeF7mI2QTDRiejN+LA9VLgLI5oARC6f8ncblseYzGwb9lmE8CxXv30oW22kQ NMiXOb+8Crb84W1tze6FWL5D6LY9tlwFwz96pmAOsCqKJ0Rlfk3PFVOxBzFUCVMN6x Mg6id3bmt4hbbqFqj+YoJ2AxPooqvOJUITZWftZ4ExmBHjpQs845+BUurrgy+2SReT rlLNZSkHx3lS9cc8P7g5YuVYremzBjzmnkaVkoftzYlwzC41OTNhqix+FO6T10mA40 X19A/UrYXIwjKc+H28ky0bfJjTk5c+E5wkvUwymsGfpEOefqoeyMRFRSp2m+58YGBz I2NnkpZQv6TCbZ49P5i5VDRKZacZ7LVYypTKo5KGdzIdFVS1XOELx5pq9R756pyqU5 VEC5xlBdUUQ75ReCfJNsIQes= Authentication-Results: mail.aegee.org/0B3JAtBQ3175681; dkim=none Received: from [192.168.1.99] (87.118.146.153.topnet.bg [87.118.146.153] (may be forged)) (authenticated bits=0) by mail.aegee.org (8.15.2/8.15.2) with ESMTPSA id 0B3JAtBQ3175681 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Thu, 3 Dec 2020 19:11:15 GMT Message-ID: <32955c218e5c3193a1a7bc5f28a40507efa30f16.camel@aegee.org> From: =?UTF-8?Q?=D0=94=D0=B8=D0=BB=D1=8F=D0=BD_?= =?UTF-8?Q?=D0=9F=D0=B0=D0=BB=D0=B0=D1=83=D0=B7=D0=BE=D0=B2?= To: Dave Crocker , John R Levine , dmarc@ietf.org Date: Thu, 03 Dec 2020 21:10:51 +0200 In-Reply-To: <02de3db94e77ddb37f329c2a886ddf90a2d3c597.camel@aegee.org> References: <2fc01257-3307-c453-18a0-bc423dccfe6a@gmail.com> <02de3db94e77ddb37f329c2a886ddf90a2d3c597.camel@aegee.org> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.39.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] Ticket #39 - remove p=quarantine X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 03 Dec 2020 19:11:23 -0000 Post Scriptum: DMARC can say one of two things: -- all mails for a domain are DKIM-signed and aligned, according to the domain owner -- not all mails for a domain are DKIM-signed and aligned (e.g. when the DMARC policy is absent, or p=none) according to the domain owner Does the DMARC specification need to propose what to do with emails in the first case above, when the DKIM-signature is not-valid/aligned? Some people will say yes. I say no: there is no need to give one of two possible advices on this (and there is no means to enforce the advice) Anyway, as I said I do not expect any consensus on this. Please consider including in the DMARC specificaiton a discussion on what is reasonable, e.g as outlined in the email below, and elaborate pros and cons on r=reject and r=quarantine. As the topic is controversal, it shall be presented as controversal in the specification. I do not follow the discussions here, I suppose that by now is addressed, that „p=quarantine;pct=0“ should be interperted as „do MLM- mungling”, and p=none to mean „no MLM mungling”. ⇐⇐⇐⇐⇐ From: Vladimir Dubrovin To: Dotzero , Vladimir Dubrovin CC: IETF DMARC WG , Дилян Палаузов Subject: Re: [dmarc-ietf] Abolishing DMARC policy quarantine Date: Fri, 14 Jun 2019 19:25:02 +0300 Nope, I mean 2 different things. 1. Why quarantine is useful (with pct=0). For example this mailing list (dmarc@ietf.org) performs From rewrite (aka From munging), e.g. dubrovin@corp.mail.ru is replaced with dubrovin=40corp.mail.ru@dmarc.ietf.org. It's because corp.mail.ru has a strict DMARC policy (reject). dotzero@gmail.com is not overwritten, because gmail.com has p=none and ietf.org only overwrites From only for domains with "quarantine" and "reject" policies. It's quite common behavior. If you are implementing DMARC for a new domain (let's say example.org), you usually start with "p=none". With p=none you receive reports for failed DMARC for different lists, like ietf.org. Before switching to stronger policy (p=reject), you may want to know which mailing list will still fail DMARC, and which lists perform From munging and, as a result, do not fail DMARC. For this purpose, before switching to "p=reject" it's useful to switch to "p=quarantine;pct=0". After this, you will only see mailing lists without From munging in DMARC reports. 2. Why quarantine should not be used with pct different from 0 If you start enforsing strong DMARC policy with "p=reject" and you have some previously uncatched misconfiguration (e.g. wrong envelope-from address in some once-in-the-month mailing), you see DMARC failures in your logs and you can react to this failures and even re-send the messages affected. If you start with "p=quarantine" you have no feedback except reports, and reports are received with a huge lag (up to 2 days) and do not provide sufficient information to catch the exact problem and you can not re-send the quarantined messages. ⇒⇒⇒⇒⇒⇒⇒⇒⇒⇒⇒⇒⇒⇒ On Wed, 2020-12-02 at 13:15 +0200, Дилян Палаузов wrote: > Hello, > > On Tue, 2020-12-01 at 15:55 -0800, Dave Crocker wrote: > > On 12/1/2020 3:17 PM, John R Levine wrote: > > > #39 proposes that we remove p=quarantine.  I propose we leave it > > > in, > > > even if it > > > is not very useful, because trying to remove it would be too > > > confusing. > > > > process, I suggest this issue gets some meaningful discussion.  My > > email > > archive indicates it hasn't gotten any discussion at all. > > This was discussed under the subject “Abolishing DMARC policy > quarantine” in June 2019.  There was no consensus.  SMTP offers this > distinciton and this is mirrored in DMARC.  In particular, senders > are > free to publish p=quarantine and receipients are free to interpret it > as p=reject.  Senders can publish p=reject and receivers are free to > interpret it as p=quarantine. > > Moreover, some destination addresses do not have the concepts of a > quarantine.  E.g an address that accepts commands for mailing lists > managements.  Such addresses can either accept or reject the message > - > there is no quarantine, so interpreting published p=quarantine as > p=reject is feasible. > > Recalling the discussion from June 2019 I do not count on any > different > consensus, if it the discussion happens here again now. > > Greetings >   Дилян From nobody Thu Dec 3 11:30: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 A89DF3A08D4 for ; Thu, 3 Dec 2020 11:30:24 -0800 (PST) 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 ZEqy1QJupSGz for ; Thu, 3 Dec 2020 11:30:23 -0800 (PST) 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 2AE243A08AB for ; Thu, 3 Dec 2020 11:30:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1607023820; bh=X1BQI5R11dL8oMmWa+CGCoXx9DwaViGriA8oU+CDWdg=; l=3275; h=To:References:From:Date:In-Reply-To; b=BJ2pytBgHUnXfrPaoTgQrxc8O/zvBu0lKUlVbl/ASZVcFgfnEwvMCpZDazGmbmJKP /epgRjgt8QAtgIBP87KAtwnD5Ve95Iul/CIlOXZfkh3N+lIcKrAQJ3sSS3YbwdmHRd yL1EnNqs2KXSXSO26KdOiKzCP2UGa50nDRTcmCmivHtcMTV+uF9X2tqolQhwl Authentication-Results: tana.it; auth=pass (details omitted) Original-From: Alessandro Vesely 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 00000000005DC03D.000000005FC93CCC.00002877; Thu, 03 Dec 2020 20:30:20 +0100 To: John R Levine , dmarc@ietf.org References: <20201202233432.D45FB28E1943@ary.qy> <479cfb50-b98e-fbbe-e7ce-375557cd624@taugh.com> From: Alessandro Vesely Message-ID: Date: Thu, 3 Dec 2020 20:30:20 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: <479cfb50-b98e-fbbe-e7ce-375557cd624@taugh.com> Content-Type: text/plain; charset=us-ascii Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Ticket #42 - Expand DMARC reporting URI functionality X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 03 Dec 2020 19:30:25 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On Thu 03/Dec/2020 18:08:50 +0100 John R Levine wrote: >>> When this came up before someone said that reports can be extremely >>> large, many megabytes. An HTTP POST or PUT is a much better way to send that. >> >> However faster, an https PUT/POST at midnight arrives later than a mailto at >> midday. > > I'm sorry but this makes no sense at all. I said so because you said https is faster. The spec is unclear about intervals, but this is matter for another ticket. > Why do you believe that people would not send reports by mail and by https > at the same time? Oh my. Hadn't thought about that. It will certainly cause duplicates. >> Yes, PUT is better than POST. >> >> How about pgp-signing the file with the dkim key? > > Sorry, that doesn't make any sense either. DKIM keys and PGP keys are > different. Hm... let me try and sign this message. $ cat delta.private | PEM2OPENPGP_USAGE_FLAGS=sign pem2openpgp "Delta selector " | gpg --import Now I have: sec rsa1148 2020-12-03 [SC] 500982D49712C507C236B2D6B8ABBBF9A091CC0D uid [ unknown] Delta selector $ gpg -u 500982D49712C507C236B2D6B8ABBBF9A091CC0D --clearsign < this text Can you verify it? I cannot find how to transform the delta selector public key into a pgp public key block. That is to transform this: $ eval $(digs delta._domainkey.tana.it txt |sed -rn -e 's/^"//' -e 's/" *"//g' -e 's/"$//p') && printf -- '-----BEGIN PUBLIC KEY-----\n%s\n-----END PUBLIC KEY-----\n' "$(echo $p |base64 -d |base64)" - -----BEGIN PUBLIC KEY----- MIGuMA0GCSqGSIb3DQEBAQUAA4GcADCBmAKBkA5YMrfcQD3kzCQJFRXLatbXbl6h07EE1TrJOVp9 4EeBV50QFuBIk0igZgPTA39O77mUyNii81hD4q2g9/Hoj9asqQHTTKjqk+gwZWC+X46K5BYSRPTC C9sidg20Laubyn0ATGaz+OyIl4JcE2rsEXwXLJ98OFEaa3gWyUVO9+lNwebs932bOtHbM2YpzJzE PQIDAQAB - -----END PUBLIC KEY----- To this: $ gpg --export --armor 500982D49712C507C236B2D6B8ABBBF9A091CC0D\! - -----BEGIN PGP PUBLIC KEY BLOCK----- mJ0EX8kn8gEEfA5YMrfcQD3kzCQJFRXLatbXbl6h07EE1TrJOVp94EeBV50QFuBI k0igZgPTA39O77mUyNii81hD4q2g9/Hoj9asqQHTTKjqk+gwZWC+X46K5BYSRPTC C9sidg20Laubyn0ATGaz+OyIl4JcE2rsEXwXLJ98OFEaa3gWyUVO9+lNwebs932b OtHbM2YpzJzEPQARAQABtCNEZWx0YSBzZWxlY3RvciA8cG9zdG1hc3RlckB0YW5h Lml0PojgBBMBCAA6FiEEUAmC1JcSxQfCNrLWuKu7+aCRzA0FAl/JJ/ICGwIGCwkI BwMCBxUKCQgLAwIEFgIDAQIeAQIXgAAKCRC4q7v5oJHMDfCfBHwKlNsrYbL+8uyb y1RBhP/epV0M9xTji9J4Tg2dHcZLgkq9odH7LbOBMuVlZxQ6ksJEVmh131CHHPCr /GmmQpsrxvpo0b5hXKRYTDqemwyvqNtWAMJpW4bLZ4XAy9c6fSICsXdfm8azKE8J jZeHlnxMnvqhctQXTFSeJ+Ijnyn2ZC31V5J2ZzCfXSpY/fxoteo= =KJkG - -----END PGP PUBLIC KEY BLOCK----- > It is hypothetically possible to sign an http transaction with DKIM Any example? > but that would be a giant distraction from what we're doing here. Should be optional, like DKIM-signing aggregate reports sent by mailto. Best Ale - -- -----BEGIN PGP SIGNATURE----- iMMEAQEKAB0WIQRQCYLUlxLFB8I2sta4q7v5oJHMDQUCX8k7GgAKCRC4q7v5oJHM DbyaBHwJ7JddtR6f9mAEF22QdZVX01ZQZagggwaqvHfXPWlD+wPafGH7Hi4dm4B+ Bh1BO/mevC5l0wYdLg5X2mTPhqNMzU+aCWz2MwdYK1iU2JQ6/KQOXpGZuhf597N0 BmRMpe56UDWt06wsE8cNUKmNiaVlJ6yaHXHSV5tUmcqXpXtGaqheAYxyY1BXepd5 KmcpmQg= =+5y4 -----END PGP SIGNATURE----- From nobody Thu Dec 3 11:44: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 7AD523A0CEF for ; Thu, 3 Dec 2020 11:44:02 -0800 (PST) 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 e9hYAMe4Sgj1 for ; Thu, 3 Dec 2020 11:44:01 -0800 (PST) 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 982213A0CCF for ; Thu, 3 Dec 2020 11:43:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1607024626; bh=/vZu4izi5bikgJfisnBb+5SUz5fmMqOcw4AaaaDOxOc=; l=2895; h=To:References:From:Date:In-Reply-To; b=DhNtuf8WSPYDexQ7lfhNo+aSFLoY/DO3C7GDBddDGdcN3Y0a9Ub7ivBjlDvvgYxRP RYQbezN1ryNHriNsN4Uh789PNLNxRS4DEsp7k37qeNg9mUXFyThUrt5vumE6nqk6r5 OMjFV+8yndOvkhrVKT0tSthLOjt0ibaUCZhode1lr5wHs4jYS8+5pjHu3qZJs Authentication-Results: tana.it; auth=pass (details omitted) Original-From: Alessandro Vesely 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 00000000005DC0D1.000000005FC93FF2.00002A03; Thu, 03 Dec 2020 20:43:46 +0100 To: "Brotman, Alex" , "dmarc@ietf.org" References: From: Alessandro Vesely Message-ID: Date: Thu, 3 Dec 2020 20:43:46 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Discussion - ARC/Extensible Reporting (Ticket #56) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 03 Dec 2020 19:44:10 -0000 On Thu 03/Dec/2020 19:54:51 +0100 Brotman, Alex wrote: > >> -----Original Message----- >> From: dmarc On Behalf Of Alessandro Vesely >> Sent: Thursday, December 3, 2020 6:24 AM >> To: dmarc@ietf.org >> Subject: Re: [dmarc-ietf] Discussion - ARC/Extensible Reporting (Ticket #56) >> >> On Wed 02/Dec/2020 20:46:54 +0100 Brotman, Alex wrote: >>> >>> While this ticket/enhancement specifically mentions ARC, I could >>> perhaps see the usefulness in other places. It seems like it would be >>> more beneficial to create a method by which other documents could >>> provide XML- based "extensions" to the report. This would allow >>> mechanisms relying on DMARC to independently define their reporting >>> schema to be included in DMARC aggregate reports. Alternately, we could >>> focus specifically on ARC, and work to include that in the base XML. >>> This means that any later reporting requirements could again require >>> changes to the core drafts.>>> >> >> >> Another possibility is for ARC to define its own report format. Hijacking >> rua= targets to send a different kind of report should be allowed. >> Otherwise, we could define a new tag, e.g. rue= (e for Extension).>> >> In either case, as we're introduce variations in aggregate report content, >> we have to devise a method for determining what version/kind of report is >> attached to a given message.>> > > We could add an element called "", and we allow ARC or whatever > it may be to exist under that element. The Aggregate Reporting document > needs to specify that any extensions are expected to be proper XML, and if > there are no extensions, an empty element is sufficient. We could create a > bit more structure as a requirement if we wanted:> > > > ... (as defined in referenced standard) > > > > If a report parser doesn't know what ARC is (or any of the extensions), it could skip the processing. I do understand this means that element may break existing parsers, even when empty, though, I expect many of the things we're proposing may fracture the expected XML. We can do a better job at producing aggregate reports with an automatically verifiable content. For example, prepending stuff like this: ... (Perhaps something better than "http://dmarc.org/dmarc-xml/0.1" for the version) But then, would the imply dmarc-xml grammar should be upgraded every time ARC (or whatever) is upgraded? Separate reports sounds simpler. Best Ale -- From nobody Thu Dec 3 11: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 44C233A097E for ; Thu, 3 Dec 2020 11:49:28 -0800 (PST) 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 GNTpUVE3WgVS for ; Thu, 3 Dec 2020 11:49:26 -0800 (PST) Received: from mail-pl1-x62d.google.com (mail-pl1-x62d.google.com [IPv6:2607:f8b0:4864:20::62d]) (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 B48603A09AD for ; Thu, 3 Dec 2020 11:49:26 -0800 (PST) Received: by mail-pl1-x62d.google.com with SMTP id f1so1730533plt.12 for ; Thu, 03 Dec 2020 11:49:26 -0800 (PST) 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=bxjHU/aP9R+LYzscsLUtniuZ6fQ2D9tGzY0O6lgr0ck=; b=Py2sDgc9TTWKij0WGsHeGlw4dtAknDFZ7cqbLC823mk0HeXExiXO+btMeh5XRFmrxG ybEIequNN7hpYOgnD5Pci7pAgS9vTMr0gu4m/HQlYeDXzfoDqk64NY/1qXOeiNaLOopW O+w5vhIE+y7eS6/eLTGEJtsXvjhVzHOqeZpM6CJRfbRibuAXkQuVaxQ0zmCiS0QEZE4Z hx/PSavI0JhKq1gZeyyFyZ4H/sATQOe05iJLTlorTW6eGoE/AlR1muPzGBv4DdfnkAhE qMdtmpLQiXQWxI2y02GVr2gjTOUWh93000xAkTQsYmfxj6P0hkY/aPAj+Ou9P/KYvs2W VG3g== 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=bxjHU/aP9R+LYzscsLUtniuZ6fQ2D9tGzY0O6lgr0ck=; b=drhO/L+SVHLELRCTl9ZoT3jcyrtJ4Ry1heJBQB2f0e5duMsdhJEn+TyzPwy+J1Sbse ery8e939jFu1Ig4jZJXkyqhyHWcNb5vW1tj+aW9r4kMofobLocGR0f+tUAIQj5MzCcZ0 w/sD/Viz9tHziibUo2nP4FLpbjD1fD6pHGTHBvtDX5oKiUxI87jqVbGblKWd30bdPkK2 Spm8kWEHcizb1LFfELSxzztYN+mOhuHmmSTO9DPaDq3xGYEjqyyUAOlu+5C5jjO2zTDN ZjXGjmJB/rPvpsH1ahuHPxTCOnviZx63x6hg5kpt/M6nq1kJqZMqMpgSf0yiUeai9UFX vu7Q== X-Gm-Message-State: AOAM533AlXbSLt/pyXFle3y5g+7H5l3lJ8IxxcV1HdcxAk1cLR6MGteZ cS+Ags/SwLFFEXi+nReCL0wpA1AMiFo= X-Google-Smtp-Source: ABdhPJw8lDdJToOXWWvfrVyGvdCVJ2muQ/rjuiNj4KmoDezHLCHwD39motbnafaOsF6Fa5K1tdUhbA== X-Received: by 2002:a17:90a:5304:: with SMTP id x4mr617496pjh.153.1607024966087; Thu, 03 Dec 2020 11:49:26 -0800 (PST) Received: from [192.168.0.109] (c-24-130-62-181.hsd1.ca.comcast.net. [24.130.62.181]) by smtp.gmail.com with ESMTPSA id 199sm2808543pfb.219.2020.12.03.11.49.24 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 03 Dec 2020 11:49:25 -0800 (PST) To: Alessandro Vesely , John R Levine , dmarc@ietf.org References: <20201202233432.D45FB28E1943@ary.qy> <479cfb50-b98e-fbbe-e7ce-375557cd624@taugh.com> From: Dave Crocker Message-ID: <505bbc06-b0f5-428e-051c-532eba23c07d@gmail.com> Date: Thu, 3 Dec 2020 11:49:23 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------5DAB542E2B83BBD44DBC3D70" Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] Ticket #42 - Expand DMARC reporting URI functionality X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 03 Dec 2020 19:49:28 -0000 This is a multi-part message in MIME format. --------------5DAB542E2B83BBD44DBC3D70 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 12/3/2020 11:30 AM, Alessandro Vesely wrote: >> Why do you believe that people would not send reports by mail and by https >> at the same time? > Oh my. Hadn't thought about that. It will certainly cause duplicates. Rather than meaning the same report will be sent by both mechanisms, perhaps he merely meant that either mechanism could be used at any time.  That is, there is no need for the choice of the mechanism to make any difference in when they get used. That is, your: > However faster, an https PUT/POST at midnight arrives later than a > mailto at midday. established a false point of distinction. d/ -- Dave Crocker dcrocker@gmail.com 408.329.0791 Volunteer, Silicon Valley Chapter American Red Cross dave.crocker2@redcross.org --------------5DAB542E2B83BBD44DBC3D70 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 12/3/2020 11:30 AM, Alessandro Vesely wrote:
Why do you believe that people would not send reports by mail and by https
at the same time?

Oh my.  Hadn't thought about that.  It will certainly cause duplicates.

Rather than meaning the same report will be sent by both mechanisms, perhaps he merely meant that either mechanism could be used at any time.  That is, there is no need for the choice of the mechanism to make any difference in when they get used.


That is, your:

However faster, an https PUT/POST at midnight arrives later than a mailto at midday.
established a false point of distinction.

d/

-- 
Dave Crocker
dcrocker@gmail.com
408.329.0791

Volunteer, Silicon Valley Chapter
American Red Cross
dave.crocker2@redcross.org
--------------5DAB542E2B83BBD44DBC3D70-- From nobody Thu Dec 3 11: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 0D2E13A09AD for ; Thu, 3 Dec 2020 11:54:09 -0800 (PST) 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 (2048-bit key) header.d=iecc.com header.b=e1lV57Vj; dkim=pass (2048-bit key) header.d=taugh.com header.b=kUHUtEQY Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9iKmQ_W9bXdy for ; Thu, 3 Dec 2020 11:54:06 -0800 (PST) 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 DEA583A0983 for ; Thu, 3 Dec 2020 11:54:05 -0800 (PST) Received: (qmail 68489 invoked from network); 3 Dec 2020 19:54:03 -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=10b87.5fc9425b.k2012; i=johnl-iecc.com@submit.iecc.com; bh=n4q9uWJvq1TcHX9m/ToI9ohaPu9eGZUS01Y3QwZswcI=; b=e1lV57VjlGQG+MWEefcilSd4Pwo5O+B2V920iNHlXBW0g6ct+5Q/Ehi3/AlK+yrWj7vXtYfP3m5WKiPWbJ+zYYrkTgys3pvz8OzEGYmLaX6mTqWX7i+XZ5Hq2SULTiXPKzL8SNNH9kWULdUv8jlX8ChRy2Fa5Q/IF1ptYJ0DHau0flEwhg9L3jqORIroZab9nhLt430hpGQ3FKDrLob0cEnEhoJIofEq/icgHKtr2i77SSsmS0ka7BS4pasfz31qYmUqSttNUB0iK1fqvWXehTlDcaOe7FWdGOVmvlfw6yRZFySMd+/JMcRDUnEedJhcBDjC3Gj7/kgiH8tFE58OQA== 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=10b87.5fc9425b.k2012; olt=johnl-iecc.com@submit.iecc.com; bh=n4q9uWJvq1TcHX9m/ToI9ohaPu9eGZUS01Y3QwZswcI=; b=kUHUtEQYqkEhX18nJm7Gh5oCzcAUL8IXpnHvmhQr0uZO4S7IMIbtmgRgatoN1caRNK0UGcTxjFNKVsetQ4pXZAMbSrmTLs0MXbo5UcYMv6y4BFZvPTjbX40y5fW/js/Idku0s8ejlggI1w0RUMNn0jvTXYFCzvWofFys0HqI01hB0EBs7iJuJuwFxsVlqbd0Id8hJpjEwp3mmylaND5rOa/DE5Q+RQ+F+LPQP4gTYJEVZGNGxQ0tFx6xbw40yBuUISh5kYIQzR/a157uaRlCzLiptkLwbBt04NUZETehv5yD9waUP4HlOi+7JehZvB336riY4+EBZ1+f3p8gZcAM/Q== 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; 03 Dec 2020 19:54:03 -0000 Date: 3 Dec 2020 14:54:03 -0500 Message-ID: From: "John R Levine" To: "Alessandro Vesely" , dmarc@ietf.org In-Reply-To: References: <20201202233432.D45FB28E1943@ary.qy> <479cfb50-b98e-fbbe-e7ce-375557cd624@taugh.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII Archived-At: Subject: Re: [dmarc-ietf] Ticket #42 - Expand DMARC reporting URI functionality X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 03 Dec 2020 19:54:09 -0000 >> I'm sorry but this makes no sense at all. > > I said so because you said https is faster. The spec is unclear about intervals, but this is matter for another ticket. For any given report, stuffing it into a web server with a PUT or POST will be faster than base64 encoding it and relaying it through mail servers. This is just arithmetic. >> Why do you believe that people would not send reports by mail and by https >> at the same time? > > Oh my. Hadn't thought about that. It will certainly cause duplicates. I meant "at the same time" as in during the same reporting run. As Dave noted, if you sent any particular report by https, there's no need to send it again by mail. Systems receiving reports have to be prepared for duplicates anyway since double deliveries of mail messages happens. That's the point of the filename on the report, to provide a unique name for each report so it's easy to tell if you've seen a report before. > $ gpg -u 500982D49712C507C236B2D6B8ABBBF9A091CC0D --clearsign < this text > > Can you verify it? I cannot find how to transform the delta selector public key into a pgp public key block. It says it can't find a public key which is not surprising. I still don't think this is a productive direction to go. If people really are worried about fake reports, there is a well defined way to put a signature in an XML document. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From nobody Thu Dec 3 14:41:12 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E11F73A0844 for ; Thu, 3 Dec 2020 14:41:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.851 X-Spam-Level: X-Spam-Status: No, score=-1.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iecc.com header.b=jXGMpyuH; dkim=pass (2048-bit key) header.d=taugh.com header.b=jjQic5Ct Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8i2Ne930u9Pj for ; Thu, 3 Dec 2020 14:41:07 -0800 (PST) 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 663FE3A0DDE for ; Thu, 3 Dec 2020 14:41:07 -0800 (PST) Received: (qmail 18911 invoked from network); 3 Dec 2020 22:41:06 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=49dd.5fc96982.k2012; bh=VOCx3RTzT775ZR0TvV/YguGE39MBtsJaGn2Ig52SgDI=; b=jXGMpyuHWkI9s3xRQRtHjgFk1LLpwvayUcZt1DYuA0FtjhA6X0gJvimPeLmqJFdS+bndGk3j70fUJY3lsAjVugnxQKwPMgVIuvknyFTjXucsBkvIH5TrWd9Q7vFUgWd90653GpOKwXS+hJix6ThbJmJpFjDPyRIE0VbOc1haRk1KOMfyYmOsqeooNtdLm847Az3GPdgRnVaHJ2XCNJLnocBqQKmhisTXInQ0vFHKf6BzqZebw3IHR+wY+BL4sCaMTGkxyHK3GVxvsfN/kfnSMiPu5sEsYeJc0GdIELHtVnsiOLz3Cush9DIpRH3YlYXQhqM21pusE3UFWRwwob35dg== DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=49dd.5fc96982.k2012; bh=VOCx3RTzT775ZR0TvV/YguGE39MBtsJaGn2Ig52SgDI=; b=jjQic5CtrphqfVHgimvlkURM7H8AQfukgWmoSwfKEBxJ1BjZMDtGov8MPZpLBoEK0VKYlFupgFpnhL/8kPbl17o/oichSgu2nsdHcAriRSs2k9DjKECywrmw0MULXC9wMdj7o5rFBOSGJXDSCT/nGkAfr34v9rY/rgnlR1axIT8QHxeokFmEE6Zxd2D+g6svJhJhDkAyOeTxTsDmIxCmpYpDvH8tRqpYv9A6t2J5eRU8QP43FUFb/EHTpc7mbc4jArGLqQMV2C83FlSMxAlfeejqVDWe9Ji2t6VOJ+ZFjSlLd5/NK2fU6Vyg5oZgz5dMRF2Lx//EzNvueTddrY4RPg== 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; 03 Dec 2020 22:41:05 -0000 Received: by ary.qy (Postfix, from userid 501) id 53A6128EFC25; Thu, 3 Dec 2020 17:41:04 -0500 (EST) Date: 3 Dec 2020 17:41:04 -0500 Message-Id: <20201203224105.53A6128EFC25@ary.qy> From: "John Levine" To: dmarc@ietf.org Cc: fenton@bluepopcorn.net In-Reply-To: Organization: Taughannock Networks X-Headerized: yes Cleverness: minimal Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] Ticket #39 - remove p=quarantine X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 03 Dec 2020 22:41:11 -0000 In article you write: >Maybe _discardable_ should be used instead. > >Why do I have a feeling of deja vu? Gee, I can't imagine. R's, John From nobody Fri Dec 4 00:21: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 CB9753A15B8 for ; Fri, 4 Dec 2020 00:21:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.12 X-Spam-Level: X-Spam-Status: No, score=-2.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, 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 OL4B2rBNfhP1 for ; Fri, 4 Dec 2020 00:21:40 -0800 (PST) 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 2DE773A15AD for ; Fri, 4 Dec 2020 00:21:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1607070097; bh=H2/LfkHc5Mj3RDV7CwGxkBt2oDqSpg90QSVrq8gISIo=; l=2197; h=To:References:From:Date:In-Reply-To; b=CvQ7t82iceHlN2vlX+cLX9r7GB+UDdAOpfCx93oMdeBbrn6r0eXjQwpCorYuxm5cf JxvUUAIt1S+lhzfZsjG0tUFhms//TM+zlMH2VEVIM/XRQZXAfvVK67LtNqbL4OSEi5 D8v2CNl/QuD+GNP8jX2Bi1GZ4wc8fsPXJh/XgX2fLIsUyakQyWLY4Fh38CCPd Authentication-Results: tana.it; auth=pass (details omitted) Original-From: Alessandro Vesely 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.000000005FC9F190.00002814; Fri, 04 Dec 2020 09:21:36 +0100 To: John R Levine , dmarc@ietf.org References: <20201202233432.D45FB28E1943@ary.qy> <479cfb50-b98e-fbbe-e7ce-375557cd624@taugh.com> From: Alessandro Vesely Message-ID: <0a650f5d-c53d-ab45-4125-6491c413f70b@tana.it> Date: Fri, 4 Dec 2020 09:21:36 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] Ticket #42 - Expand DMARC reporting URI functionality X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 04 Dec 2020 08:21:42 -0000 On Thu 03/Dec/2020 20:54:03 +0100 John R Levine wrote: >>> >>> Why do you believe that people would not send reports by mail and by https >>> at the same time? >> >> Oh my.  Hadn't thought about that.  It will certainly cause duplicates. > > I meant "at the same time" as in during the same reporting run.  As Dave noted, > if you sent any particular report by https, there's no need to send it again by > mail. Got it. However, the spec says it's a list of addresses to which aggregate feedback is to be sent. When there are multiple entries, up to now, reports are sent to each. If services like dmarcian switch to an https URI, a sender could end up with that URI along with its local mailto one. How does a report producer know whether multiple URIs are mutually exclusive or inclusive? > Systems receiving reports have to be prepared for duplicates anyway since > double deliveries of mail messages happens.  That's the point of the filename > on the report, to provide a unique name for each report so it's easy to tell if > you've seen a report before. Right, but if that happens everyday the (small) efficiency gain is lost. >> $ gpg -u 500982D49712C507C236B2D6B8ABBBF9A091CC0D --clearsign < this text >> >> Can you verify it?  I cannot find how to transform the delta selector public >> key into a pgp public key block. > > It says it can't find a public key which is not surprising.  I still don't > think this is a productive direction to go. Not for the subject at hand, maybe. The possibility to further deploy DKIM key distribution by coding some dkim2openpgp utility seems interesting to me. > If people really are worried about fake reports, there is a well defined way to > put a signature in an XML document. However, XML signatures require a certificate, not just a key. Consider that a DNSSEC-authenticated DKIM signature is semantically superior to CA certificates. First, because registrars know what they're signing better than CAs. Second, because the way to associate DKIM signatures with the issuing domains is better standardized than X509 subject common name or alternative name. Best Ale -- From nobody Fri Dec 4 03:10:36 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78FB63A09C6 for ; Fri, 4 Dec 2020 03:10:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.12 X-Spam-Level: X-Spam-Status: No, score=-2.12 tagged_above=-999 required=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.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 EtO9Hh_oCKau for ; Fri, 4 Dec 2020 03:10:32 -0800 (PST) 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 84B6A3A09C4 for ; Fri, 4 Dec 2020 03:10:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1607080228; bh=Obe1tfuB3p8C3dODDBxqzjoOpT3CmF4DCfGT4sIlZFg=; l=2001; h=To:From:Date; b=BMlLFE9usEo4FtATQ1cLgWbTqKvPg2dCngx/kY2b4UzQFkuaMV1sXuJBcZhN/c5FC yxoN/eoZ+qsAFANb/cn08Q2RlKjGIvc+KN/+GLoSSsWXFpAFqTtEE1PHO5gdammm2V +iS+EWGkCLGeUuU/OVhhxBWalKCGSaJ3fnX0yMUzwnrYEP/pI42cBFLe7hpwx Authentication-Results: tana.it; auth=pass (details omitted) Original-From: Alessandro Vesely 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.000000005FCA1924.00003BF2; Fri, 04 Dec 2020 12:10:28 +0100 To: dmarc-ietf From: Alessandro Vesely Message-ID: <0408ae98-e1c1-71fe-fdd4-8bc7a7c151d3@tana.it> Date: Fri, 4 Dec 2020 12:10:28 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [dmarc-ietf] Ticket #28 - Failure report mail loops X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2020 11:10:35 -0000 We would like to close this ticket by Dec 18, two weeks from now, so please get on it. The ticket originated from John's comment, in May 2019: Apropos recent discussions, we could recommend that failure reports be rate limited per recipient both to break loops and to deter indirect mail bombing. The current draft discusses the topic toward the end of the introduction of Section 3, before the first subsection: An obvious consideration is the denial-of-service attack that can be perpetrated by an attacker who sends numerous messages purporting to be from the intended victim Domain Owner but that fail both SPF and DKIM; this would cause participating Mail Receivers to send failure reports to the Domain Owner or its delegate in potentially huge volumes. Accordingly, participating Mail Receivers are encouraged to aggregate these reports as much as is practical, using the Incidents field of the Abuse Reporting Format ([RFC5965]). Various aggregation techniques are possible, including the following: * only send a report to the first recipient of multi-recipient messages; * store reports for a period of time before sending them, allowing detection, collection, and reporting of like incidents; * apply rate limiting, such as a maximum number of reports per minute that will be generated (and the remainder discarded). Some issues the WG may want to consider: 1. That whole passage should be moved to its own subsection of Section 5, "Security Considerations". Only a reference should be left in the intro. 2. In the first *-bullet above, the sense of multi-recipient is ambiguous. An explicit mention of ruf= might help. 3. The 2nd and 3rd *-bullets may need expansion. Propose text in case. 4. Some explicit loop prevention specification may be added. For example: 4.1. send reports from a subdomain having a DMARC record without ruf=, or 4.2. never send failure reports about failed reports. Best Ale -- From nobody Fri Dec 4 10:21: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 615BE3A0A83 for ; Fri, 4 Dec 2020 10:21:39 -0800 (PST) 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 (2048-bit key) header.d=iecc.com header.b=gSJAbOhu; dkim=pass (2048-bit key) header.d=taugh.com header.b=ThFERM8z Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2udhQ8ZoftqH for ; Fri, 4 Dec 2020 10:21:37 -0800 (PST) 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 487BA3A0A7E for ; Fri, 4 Dec 2020 10:21:36 -0800 (PST) Received: (qmail 73731 invoked from network); 4 Dec 2020 18:21:34 -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=12000.5fca7e2e.k2012; i=johnl-iecc.com@submit.iecc.com; bh=U6ZXO5Dm/K9278WGGAa3gjzH0ZnMya7ph1qbaCM6Ynw=; b=gSJAbOhuVdEU8R9LjIh14ebIP8yJFvbhM2Kc61XQajb3KykEzrOuJr/nXadqqebxxDS7K1OkC9AHxPvefGbT8DavNINBKIlhDd79bLqATv1svmduIA4G3GOCo7RPCqydEaulElViVgqKoCn7IYqPlfiSdgDxp3t18ZuvUYUSXjqwEYxTyzBm9tX6t8L8DE8UpkDHk7KJ+ged9jr8IietQff2fq9IZ+hGvgt4s0C8kZh5vDF12ECE191PO3AaTOOWyyhKqiMt2UAU5KO69XZL5Efm6/1iuqwKO7qPakWH4C94IAaLOBbLa0OTuBlikUhvdGSlbNEbS/sTFTz55+Fv1A== 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=12000.5fca7e2e.k2012; olt=johnl-iecc.com@submit.iecc.com; bh=U6ZXO5Dm/K9278WGGAa3gjzH0ZnMya7ph1qbaCM6Ynw=; b=ThFERM8zYeoa/Z3Eq6bhbwyMt7Uelmi4s/dAGLyE+LzcL58O0YbyGd3j32ztydo/G2wY47fI2whnXXIMNZtUcNbQPPugfbVpp6cjycnZj2jXBRLrBUdvHZYibjuC3Zl7ZnAWM5Y2OAO87KthjW7YJBTHTrrtRivbeUGemVXn5TZOMIpO/1Bp7XRd6iXYo7FTmWa+MWRhLcURh/mgi0VL1cvFn974n02CQ+ShQKaIHl8yJZJomwNix0oLXvvx6xutA/CTa1+NcZbmin4/2tUF3RERNjQWlEf23oTw57J6uU91UDgsTPH/Zfp0k5cBSQSVIBZuT4/9O6soaIy2ZG2grg== 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; 04 Dec 2020 18:21:33 -0000 Date: 4 Dec 2020 13:21:33 -0500 Message-ID: From: "John R Levine" To: "Alessandro Vesely" , "John R Levine" , dmarc@ietf.org In-Reply-To: <0a650f5d-c53d-ab45-4125-6491c413f70b@tana.it> References: <20201202233432.D45FB28E1943@ary.qy> <479cfb50-b98e-fbbe-e7ce-375557cd624@taugh.com> <0a650f5d-c53d-ab45-4125-6491c413f70b@tana.it> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="0-2145378558-1607106093=:31576" Archived-At: Subject: Re: [dmarc-ietf] Ticket #42 - Expand DMARC reporting URI functionality X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 04 Dec 2020 18:21:39 -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-2145378558-1607106093=:31576 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT >> I meant "at the same time" as in during the same reporting run.  As Dave >> noted, if you sent any particular report by https, there's no need to send >> it again by mail. > > Got it. However, the spec says it's a list of addresses to which aggregate > feedback is to be sent. When there are multiple entries, up to now, reports > are sent to each. Hm, we might want to revisit that. If a domain wants mail sent to three places, it's not like it's hard to arrange for forwarding. My intention is that if you send the report by https, you're done. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly --0-2145378558-1607106093=:31576-- From nobody Fri Dec 4 11:23: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 EBF7C3A0EDE for ; Fri, 4 Dec 2020 11:23:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 3ZniO4jhkFvN for ; Fri, 4 Dec 2020 11:23:40 -0800 (PST) Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-eopbgr20115.outbound.protection.outlook.com [40.107.2.115]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AFE603A0EDB for ; Fri, 4 Dec 2020 11:23:39 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Jv47qKn/kgPcYOus83P3QPL/bAHYN2dmnGcTogyfz7TdW+vbPzf2eZKKgHOACGh6OAP/5J4cew+UjzYMtr1VlTihZvMY6KKQAIOpqUFdMZXsQ8yDdEf/i3Z2lVbbWrems+b0rcx1UhWoAZgykUijIdX+n0+VUEUMCTCRAHEoqt1ahEdLSyl+G8080KIIIpnRJvVx4+zGjRwRYtokTuGbAnoYkJMOKe0wKR/a4d2ksAKvaiRZuwyQCOQpW2naIgkPVPTm6pHQUes8Noes/cbockWETjW9fYSqQQDz6yrCxDurIatgPueYLQ5GEwFd2XuRF/9WVKm0juON6h6Jkby/OQ== 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=je58wtNJCA+wF4+xrugbH+EK3dHd10SJ6jpoM3yQTFI=; b=eGT7YaMdevUGY/Jq2a4FKInx/16b/E2sIXmQgxG/xBRAkY1pqfZ76oASop4Fjqh75y++L6eWkRIPGcBtyOHIqZ/EpHLJuKp1TMHkvYWfKp7r72wK9b0MMYekzPEfeVOFV3cfJ8r6768u7KZ/eN9gjMqptD8dHa5bDKtgNWSut81KSjXOSAUz+RzsFt8S+w/SzTdaG9e8aUl5XQvDGJI+Lg9ph63IzvHZkn9c3T9qdfN5pN0YqwVID0KQWcrPbV3X5GRu+/Mfy1bZofzBGbG3dNbo5HC83NpwB0BjtZ9JIKq56w2JX7tdzC95PvNRzZ/VvmNrk4x9O+gPPUVpaRkYEg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=wemonitoremail.com; dmarc=pass action=none header.from=wemonitoremail.com; dkim=pass header.d=wemonitoremail.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wemonitoremail.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=je58wtNJCA+wF4+xrugbH+EK3dHd10SJ6jpoM3yQTFI=; b=pNsee24vy6En5rF5Rs5oP648EQTwnbFgPJ2CDLNRCzFDVaKQPCjUdxRTTswzJvsTjmprswy0gOIXnXtTr1bPjdkrEurJ/XngmjbjMea+OM2eIUtLyeFeT+bGITIQYtkurW+WojOSObdYOATUfIl2eL4OgC3w9lp/OAAlx8yLhjZprCY2cdo/bjLhMP77NEYxV4ITxCUzqrq8npbZqmG7VtlLQfr9d99IDtCB/RJpax9e/UzsCZeDAVwbqnS5q9avQmcPSQukL5xdcUpQE4zv76Kp/ycAAPGotx4/6A4ixMczHoUvbSG4RUrE+VJfjN4mDlrLe3+LipWT11eCx2HeTw== Received: from VI1PR01MB7053.eurprd01.prod.exchangelabs.com (2603:10a6:800:19a::9) by VI1PR01MB6559.eurprd01.prod.exchangelabs.com (2603:10a6:800:180::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3632.18; Fri, 4 Dec 2020 19:23:34 +0000 Received: from VI1PR01MB7053.eurprd01.prod.exchangelabs.com ([fe80::4839:b26:a604:336d]) by VI1PR01MB7053.eurprd01.prod.exchangelabs.com ([fe80::4839:b26:a604:336d%5]) with mapi id 15.20.3632.017; Fri, 4 Dec 2020 19:23:34 +0000 From: Ken O'Driscoll To: "dmarc@ietf.org" Thread-Topic: [dmarc-ietf] Ticket #42 - Expand DMARC reporting URI functionality Thread-Index: AQHWyDBplg5u91qkckS1PWHOZHF+jKnjmUSAgADdugCAANtLgIAAS0YAgAAniQCAAAaggIAA0N0AgACnoICAAATa4A== Date: Fri, 4 Dec 2020 19:23:34 +0000 Message-ID: References: <20201202233432.D45FB28E1943@ary.qy> <479cfb50-b98e-fbbe-e7ce-375557cd624@taugh.com> <0a650f5d-c53d-ab45-4125-6491c413f70b@tana.it> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=wemonitoremail.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: a65cc92a-948c-4743-209b-08d8988a17f4 x-ms-traffictypediagnostic: VI1PR01MB6559: 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: xHUG3DbJ79b4N8W8VAx0FgeWa8bmyxmW7pJK9xlTWXzZAgqYHtdRML0j+/V2iaGhYOHMSq6qk2YPKtT32lL2F1Qhcwe+By2lJMy2QOZaWylGazu2XYCGnsbQ8uTWB35EIDD3YjWlCNVujg4DiebGfLfHhcHvdkkkjSDB1zckew5J/JR+mK0TuszGXgZ2iVTiK6+1KdmJksuPaLtQ2OMm+UiLE6792abYTp9mieR225HEw1dAG30ToqDAU/fp1X+wsgBhOAGuSzp1cA4RNhPy6BOEx7b9aO63x3oXOlFi7YC9QQ6nSsvWOxuEUzeiX7ZA4WXWvBaNi3ymmrs3bGl9mA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:VI1PR01MB7053.eurprd01.prod.exchangelabs.com; PTR:; CAT:NONE; SFS:(366004)(39830400003)(376002)(396003)(136003)(346002)(9686003)(2906002)(316002)(8676002)(55016002)(7696005)(478600001)(71200400001)(53546011)(83380400001)(8936002)(33656002)(6916009)(66556008)(52536014)(5660300002)(76116006)(66476007)(6506007)(66946007)(64756008)(66446008)(26005)(86362001)(186003); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: =?utf-8?B?NDMxaTB0ZDU4YzVuNGVjd2hqS1lrVzFwanhVNHQ5YTdZQkxJSkkxVFJKbzdV?= =?utf-8?B?U1VPcVEwakZJcGoyQkd0ZEZ2VjBmRXFvd3Y2OGZyOWovbFpGaGdSRDRwR0Ex?= =?utf-8?B?Y3JzVXZ2VmJWU0JWc1YrQ01vQ042K01sZnZYclZJVTE4UDlBd1pEeGxOUEhH?= =?utf-8?B?Q3VsRzBOMm16RG5hYWcrc2dMNDhsWmJERHBRUExXOHBZNlpOd1VxT1o2WXRT?= =?utf-8?B?L1lTYXh4M2lQdVpTVTU1OW5PNmVKMW4wR3gxUkZIUnJJOTR3QXEyUytKMXJR?= =?utf-8?B?bG5NYXZXM0RIWDlQbEh0TVFqS0hCWEEzVStjR0NoVTJPalQ2WjJwVUJHNVRS?= =?utf-8?B?cVByYkNERTV6alNTK2ZoWGdOT1hLclhHSUxZd09NbnNUMERjeHNkUjkxRytL?= =?utf-8?B?TUM4MTlJZXVCR285S2tlSTcySGZiaTBzK1p6UzhZdk5JWi80N3ByOE0xSEwz?= =?utf-8?B?UTE1Ynh2bHJIMzFyd2J1Sjc3R01ZY2V1K3JyR1U4T2RWeVgyODBHbHhDZkhK?= =?utf-8?B?N21QQ2V5SDJyVjRYSElJdThaVEFHcGxuQ20wRSt1ZmJJdWhGU2VFQ1RUT3JK?= =?utf-8?B?YTRSWVZOYXp6NEZaZERrZDhYTHN3Q1FOV0ZxcVBQc0ttL0VuNEhzQVNVSW9s?= =?utf-8?B?dnhYTTROOGNoSHg1MUlXVzRnNVJkYUo2R1JkRDJjYUl2UFBVUzVaQ3ZnY09S?= =?utf-8?B?QWRZOVUwaE8rLzBBcnRhdHJsdnZ0MDRsTERMTWRpN3hjZEJralNneVU2S0dH?= =?utf-8?B?cGtOY3JCSCs1cWlZcWp5c3AyL0lZRE5TSW93T0FmVDRBaFBTbTRvaEt0eUti?= =?utf-8?B?clNZNytxN1JUaWtuVTUySGxEMFJzQ0tSVFFwendaRkNhQWVoVTViendsRUlq?= =?utf-8?B?RGVsYTMrOWcrRnlLWldMb0JyelRhVlJtN2M1RzlXR1J0Vm9mNWZWbHgvdC9D?= =?utf-8?B?VmtPNWNFTU1HZzFFVEE0WU5Md3dDdThUUWsrS0VZNXhSKzE2bXF6SDhMb0s5?= =?utf-8?B?S0I3dG1CbU1haXNrZUdjaVZxemZWVmxrVHBCdlNnVW5TZzg0OE0xWXo3MXUw?= =?utf-8?B?YjMzUkkwaW93MkpIOFpnaGtUS2YwQi9PNlZ5WkEvSEo4alZ3RStvVXFLckp6?= =?utf-8?B?WnhHOUxLcmwwYkgvNFpyL3BBTko0KzF5WUMxK1ZwSWtMc0dKOG5pVVc0WHdF?= =?utf-8?B?aG9jZGhaQVpjWUxTUjRtTkM4T1dSc0xJK2dyK0c0L3pYYmpHeTc4Tm1kODFv?= =?utf-8?B?K0hlandFUjdyS0ZNVDl4c3I1YVE0R2c4M05zM2NsRUpJeDM1WjJXUXd2K0Nz?= =?utf-8?Q?896tZM3aQI9zc=3D?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: wemonitoremail.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: VI1PR01MB7053.eurprd01.prod.exchangelabs.com X-MS-Exchange-CrossTenant-Network-Message-Id: a65cc92a-948c-4743-209b-08d8988a17f4 X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Dec 2020 19:23:34.7300 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: a2b1d6fe-fc8b-4b7c-b9f1-d7b1ab3d23b3 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: j9d87vmia/kO0CfZrjkhF4qY89AM0wLE/RbQ6/3xOr7rgVNRzth+1oBfOg5kTLtv0jMtqjN287LJv89xPOmNUw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR01MB6559 Archived-At: Subject: Re: [dmarc-ietf] Ticket #42 - Expand DMARC reporting URI functionality X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 04 Dec 2020 19:23:42 -0000 PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBkbWFyYyA8ZG1hcmMtYm91bmNl c0BpZXRmLm9yZz4gT24gQmVoYWxmIE9mIEpvaG4gUiBMZXZpbmUNCj4gU2VudDogRnJpZGF5IDQg RGVjZW1iZXIgMjAyMCAxODoyMg0KPiBUbzogQWxlc3NhbmRybyBWZXNlbHkgPHZlc2VseUB0YW5h Lml0PjsgSm9obiBSIExldmluZSA8am9obmxAdGF1Z2guY29tPjsNCj4gZG1hcmNAaWV0Zi5vcmcN Cj4gU3ViamVjdDogUmU6IFtkbWFyYy1pZXRmXSBUaWNrZXQgIzQyIC0gRXhwYW5kIERNQVJDIHJl cG9ydGluZyBVUkkNCj4gZnVuY3Rpb25hbGl0eQ0KPiANCj4gPj4gSSBtZWFudCAiYXQgdGhlIHNh bWUgdGltZSIgYXMgaW4gZHVyaW5nIHRoZSBzYW1lIHJlcG9ydGluZyBydW4uwqAgQXMNCj4gPj4g RGF2ZSBub3RlZCwgaWYgeW91IHNlbnQgYW55IHBhcnRpY3VsYXIgcmVwb3J0IGJ5IGh0dHBzLCB0 aGVyZSdzIG5vDQo+ID4+IG5lZWQgdG8gc2VuZCBpdCBhZ2FpbiBieSBtYWlsLg0KPiA+DQo+ID4g R290IGl0LiAgSG93ZXZlciwgdGhlIHNwZWMgc2F5cyBpdCdzIGEgbGlzdCBvZiBhZGRyZXNzZXMg dG8gd2hpY2gNCj4gPiBhZ2dyZWdhdGUgZmVlZGJhY2sgaXMgdG8gYmUgc2VudC4gIFdoZW4gdGhl cmUgYXJlIG11bHRpcGxlIGVudHJpZXMsIHVwDQo+ID4gdG8gbm93LCByZXBvcnRzIGFyZSBzZW50 IHRvIGVhY2guDQo+IA0KPiBIbSwgd2UgbWlnaHQgd2FudCB0byByZXZpc2l0IHRoYXQuICBJZiBh IGRvbWFpbiB3YW50cyBtYWlsIHNlbnQgdG8gdGhyZWUNCj4gcGxhY2VzLCBpdCdzIG5vdCBsaWtl IGl0J3MgaGFyZCB0byBhcnJhbmdlIGZvciBmb3J3YXJkaW5nLiAgTXkgaW50ZW50aW9uDQo+IGlz IHRoYXQgaWYgeW91IHNlbmQgdGhlIHJlcG9ydCBieSBodHRwcywgeW91J3JlIGRvbmUuDQoNCklu IG1hbnkgY2lyY3Vtc3RhbmNlcywgbWFpbCBmb3J3YXJkaW5nIG1heSBiZSBxdWl0ZSBkaWZmaWN1 bHQgdG8gYXJyYW5nZS4NCg0KTWFueSBvcmdhbmlzYXRpb25zIHVzZSBhbiBleHRlcm5hbCBzZXJ2 aWNlIHRvIGhhbmRsZSB0aGVpciByZXBvcnRzLiBDdXJyZW50bHksIGlmIHN1Y2ggYW4gb3JnYW5p c2F0aW9uIHdpc2hlcyB0byBhZGQgYW5vdGhlciByZXBvcnQgcmVjZWl2ZXIsIHRoZXkgYXJlIGlu IGNvbnRyb2wgb2YgdGhhdCBwcm9jZXNzIGJ5IG1vZGlmeWluZyB0aGVpciBETlMgem9uZS4NCg0K SG93ZXZlciwgaWYgdGhleSBjYW4gb25seSBzcGVjaWZ5IG9uZSByZXBvcnQgcmVjZWl2ZXIgdGhl biBpdCBpcyB0aGF0IHJlcG9ydCByZWNlaXZlciB3aG8gbXVzdCBoYW5kbGUgYW55IGZvcndhcmRp bmcgaW4gdGhlIGNhc2Ugb2YgbXVsdGlwbGUgcGFydGllcy4NCg0KVGhlIHByZSBhbmQgcG9zdCBh Y2NlcHRhbmNlIGZpbHRlcmluZyB0aGF0IG1vc3QgbWFpbGJveCBwcm92aWRlcnMgaW1wbGVtZW50 IGNhbiBtYWtlIHRoZW0gdW5yZWxpYWJsZSBmb3IgZGVsaXZlcmluZyBETUFSQyByZXBvcnRzIHRv IHVzZXIgbWFpbGJveGVzLiBTbywgYW4gb3JnYW5pc2F0aW9uIHdvdWxkIGxpa2VseSBoYXZlIHRv IHNldCB1cCBhIHNlcGFyYXRlIG1haWwgaW5mcmFzdHJ1Y3R1cmUgc2hvdWxkIHRoZXkgd2lzaCB0 byByZXRhaW4gY29udHJvbCBvZiB3aGF0IHBhcnRpZXMgcmVjZWl2ZSB0aGVpciBETUFSQyByZXBv cnRzLg0KDQpPZiBjb3Vyc2UsIHRoaXJkIHBhcnR5IHJlcG9ydCBwcm9jZXNzaW5nIHNlcnZpY2Vz IGNvdWxkIGFsc28gYWRkIHN1cHBvcnQgZm9yIHN1Y2ggZm9yd2FyZGluZy4gQnV0LCBnaXZlbiB0 aGF0IHN1Y2ggYSBmZWF0dXJlIGNvdWxkIGZhY2lsaXRhdGUgYSBjb21wZXRpdG9yLCBJJ20gc2Nl cHRpY2FsIGl0IHdvdWxkIG1ha2UgYnVzaW5lc3Mgc2Vuc2UgdG8gbWFueSBvZiB0aGVtLiBPbiB0 b3Agb2YgdGhhdCwgaXQncyBlYXNpZXIgdG8gcmVjZWl2ZSB0aGFuIHNlbmQgc28gdGhlcmUgaXMg YW4gb25nb2luZyBjb3N0IGluIHByb3ZpZGluZyBlbWFpbCBmb3J3YXJkaW5nLg0KDQpBcyB0byB0 aGUgdXRpbGl0eSBvZiBoYXZpbmcgbW9yZSB0aGFuIG9uZSByZXBvcnQgZGVzdGluYXRpb24sIEkg cmVndWxhcmx5IHJlY2VpdmUgY2xpZW50IERNQVJDIHJlcG9ydHMgb24gdG9wIG9mIHRoZWlyIGV4 aXN0aW5nIHNlcnZpY2UgYXMgcGFydCBvZiBjb25zdWx0YW5jeSBlbmdhZ2VtZW50cy4gSXQgaXMg YWxzbyB0aGUgb25seSB3YXkgZm9yIGFuIG9yZ2FuaXNhdGlvbiB3aXRob3V0IHRoZWlyIG93biBl bWFpbCBpbmZyYXN0cnVjdHVyZSB0byBzaW11bHRhbmVvdXNseSBldmFsdWF0ZSBtb3JlIHRoYW4g b25lIHJlcG9ydCBwcm9jZXNzaW5nIHNlcnZpY2UuIFNvIEkgYmVsaWV2ZSB0aGVyZSBpcyB1dGls aXR5IHRoZXJlLg0KDQpLZW4uDQo= From nobody Fri Dec 4 11:58: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 B56C53A07EA for ; Fri, 4 Dec 2020 11:58:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.851 X-Spam-Level: X-Spam-Status: No, score=-1.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iecc.com header.b=IR3VA7UT; dkim=pass (2048-bit key) header.d=taugh.com header.b=WMlOrHHa Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6FDvxyUFvKSE for ; Fri, 4 Dec 2020 11:58:37 -0800 (PST) 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 7F73A3A0794 for ; Fri, 4 Dec 2020 11:58:36 -0800 (PST) Received: (qmail 11385 invoked from network); 4 Dec 2020 19:58: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:cleverness; s=2c77.5fca94ea.k2012; bh=dLnP65IgZBemFJ1NStgGpgnv+TKXP7gS5dbhNeCviS4=; b=IR3VA7UTi/lIsBfaIYTc9LPm8dqQoSVXRaq60L+pKcUtP1V/Cm1KIyFzs3w/YdVd8kRaPgTA/3iQuTuoNrQXNiyf0D0prmLA0LI9YL0U075lpIqJR7EUuYOwGIdKblYetnEOqzXOdIUSzxSmYAs54kJiU1f9rf/rzfMoX2MtGWLJ/yrkq5i5yqLtaH/KEyMHYUvm4+p2nLGMzsVDEgtITwf+Kgxd3E1Pa+GmXpWIiAHcx78vgX5SmdjkhzwR4xLqHHOV5zejz92xs1WlCDW4lYWHAruN16lCqZmHCo53Nmhq4se/51rd1BAk13+tuh/sDx3C1jQKf/WmjomhE1k6hg== DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=2c77.5fca94ea.k2012; bh=dLnP65IgZBemFJ1NStgGpgnv+TKXP7gS5dbhNeCviS4=; b=WMlOrHHaStnTTdvEdJs2u84/CC24xRf2BFSZO/ncsYDhPvi6YHFC2BU12iY79J8r8B61kyLZe1BreBwegQZB7vgg73/YA3n2EExDEc0l0sGnZ4IjJQMITvTMJjEjstssynX5McoI0yf7zcPnxXPccaP0EY0xCIUlh3y1OLzIXCU6weF4e8akd0+jt8boWAQ2GkIfdm+V1jb9LQRhNc0wrjSCmiRIGGxK+um8OOu/oz8Y95v+4f+b/pVJjsPHd9Fa+8H1P/j3pkAgkF98FKmZjK1HcO+W4wMR5RMaJBpEvAZcqtwY00QckkqoBb9bTQGC8Monq5m6t2l0S1gMQ3Qt3A== 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; 04 Dec 2020 19:58:34 -0000 Received: by ary.qy (Postfix, from userid 501) id 6B48A28F892A; Fri, 4 Dec 2020 14:58:33 -0500 (EST) Date: 4 Dec 2020 14:58:33 -0500 Message-Id: <20201204195833.6B48A28F892A@ary.qy> From: "John Levine" To: dmarc@ietf.org Cc: vesely@tana.it In-Reply-To: <0408ae98-e1c1-71fe-fdd4-8bc7a7c151d3@tana.it> Organization: Taughannock Networks X-Headerized: yes Cleverness: minimal Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] Ticket #28 - Failure report mail loops X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2020 19:58:40 -0000 In article <0408ae98-e1c1-71fe-fdd4-8bc7a7c151d3@tana.it> you write: >We would like to close this ticket by Dec 18, two weeks from now, so please get >on it. > >The ticket originated from John's comment, in May 2019: > > Apropos recent discussions, we could recommend that failure reports be > rate limited per recipient both to break loops and to deter indirect > mail bombing. I have never gotten enough failure reports that handling them was even slightly inconvenient, and my addresses are on every spam list in the world. Has anyone else? If don't have evidence that this is a real problem, I'd just close the ticket. R's, John From nobody Fri Dec 4 13:41: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 497103A0C87 for ; Fri, 4 Dec 2020 13:41:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.651 X-Spam-Level: X-Spam-Status: No, score=-1.651 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mtcc-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JOnuD1XvX9DZ for ; Fri, 4 Dec 2020 13:41:32 -0800 (PST) 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 57CC63A0C83 for ; Fri, 4 Dec 2020 13:41:32 -0800 (PST) Received: by mail-pg1-x52d.google.com with SMTP id n10so4328610pgv.8 for ; Fri, 04 Dec 2020 13:41:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mtcc-com.20150623.gappssmtp.com; s=20150623; h=to:from:subject:message-id:date:user-agent:mime-version :content-transfer-encoding:content-language; bh=7jb6iAZ3JPPx70WuDnOHJ0+rQlNlOOAhSI71LoLwp+k=; b=rgT4iD9HVZni2RcIncDs9vUSEJoX9Yv2zsqgimjzcKn9JCvMcoYnQ/GctiXyAC95kK b3673HqnUfmrwFHS8a6fCknK2jsySiX7traXEVLpOaLb/MlAlrDQqJxtWL9PLTbieyBX /Vgr3lFm22JEW1ml8c+L3gq8oscnvScbeg4Lr9BXKBRVvsiQi4QwMhJ02IRFV2nIS+aV VMRlgBNyavDqGcPksVyJLOqEqik/FyRxlxYpeK4HEn/P/a8Fam46GIVIhhYRYi9P7tWT yQsouPWVYbLzCCNRn9vFMd1Y57gjwGtf+rQqZAx92Ub6JWmvg2M46c/pU0WfFXqKtu+B BtRQ== 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-transfer-encoding:content-language; bh=7jb6iAZ3JPPx70WuDnOHJ0+rQlNlOOAhSI71LoLwp+k=; b=BSlCfPjhmp7tTNtrK71GhL4dNhbclCOw530whrCIx5nAh2ktjuUZ5AWjYQYwhDHf91 XhyLqzw1XxwDfrnB4UbsxAt2et6urRXtTPKsE4JX41vOOoKmUn7kUU7zgO6tg19guBJf 5+BP4MoW7IrHrwZldP3+d2AR/1ZL0yjQQvxJWFBdplkVhkepKFnuO/i5Q/qxo1w1SAE1 +rjS1KJZ7Wb9kXGepOuwsujKitqQhMjB+RtJTiCqMOLOVzY5FM5NJ6RECYJhLJsVEMNG 1hNzZrKJwOerxsnmTGVYVLfNS7X+iwcIYxJgGw2dG9e33ZQINd+Jx/2ITtip84qduJen j0Lw== X-Gm-Message-State: AOAM530DEWeSRSrbhvxOzvMNj9MY0ysFYnLcxtd8lPHWaeIoq5g20a45 IMHMjvTu1OL0IRWCSfiQp2JBCWS8YAFGPw== X-Google-Smtp-Source: ABdhPJzA60MleC2UyUXfVAQ/1NterlZf+1X/xyE3B7uAPjgDv+Vr8k89lK1s0DtamYqO9l5gqJOoog== X-Received: by 2002:aa7:843a:0:b029:19d:b279:73c9 with SMTP id q26-20020aa7843a0000b029019db27973c9mr5623706pfn.3.1607118091063; Fri, 04 Dec 2020 13:41:31 -0800 (PST) Received: from mike-mac.lan (107-182-42-33.volcanocom.com. [107.182.42.33]) by smtp.gmail.com with ESMTPSA id mr7sm2991895pjb.31.2020.12.04.13.41.29 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 04 Dec 2020 13:41:30 -0800 (PST) To: "dmarc@ietf.org" From: Michael Thomas Message-ID: <134860ee-5fbf-2fb3-a5b3-4be68806ab22@mtcc.com> Date: Fri, 4 Dec 2020 13:41:28 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: [dmarc-ietf] is DMARC informational? X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 04 Dec 2020 21:41:33 -0000 Is my google fu completely failing me, or is RFC 7489 not the DMARC protocol spec? If it's informational, how did that happen? Mike From nobody Fri Dec 4 14:27: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 F01563A0ECB for ; Fri, 4 Dec 2020 14:27:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=valimail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qs5eeZd-XQvm for ; Fri, 4 Dec 2020 14:27:13 -0800 (PST) Received: from mail-qt1-x82f.google.com (mail-qt1-x82f.google.com [IPv6:2607:f8b0:4864:20::82f]) (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 E69093A0D93 for ; Fri, 4 Dec 2020 14:27:12 -0800 (PST) Received: by mail-qt1-x82f.google.com with SMTP id a6so2741225qtw.6 for ; Fri, 04 Dec 2020 14:27:12 -0800 (PST) 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=CQBkdgS2oSTnhgOjx4Huj+Ee9TqtVYFB1IxYrJvoTkI=; b=IsVoDrSBGub/XbwkBt8bHDAzVqiRmwdIXnvNSwn36nxY9lyVjX94NPw6t8G3VLQdut iDOcb42sCwBddgeZLbPjoDf9D0jx6J/3begZFIKdCAzGBzBqVDY9evNw4SFwLE25vhTq twpKSOqf6TlJ4l7r8b4OXJWfMQO0cT7MSB/wEEKGwEzqM7iY8DqNIkskzoZRik5WCIe6 bPx2LXjYnemrjUALoxDsA4TrOZuxcLKNHXEKgJJmqyGKoCU/sZWRija3AV64QHXlXm0h 2ngelWhx3aTfp/M0qAx7gf6ICixP5ZjCnvqDRloMPmls6GZLQS/i0x8IqUD8XkvM1V7Q hNcQ== 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=CQBkdgS2oSTnhgOjx4Huj+Ee9TqtVYFB1IxYrJvoTkI=; b=S8V7i4GNb3t1bZVB8PYzlFf8rf9/A1/7cx5+qK02WOxWrJ6FRT+DlK7Wg0IENNK7tb VLbfjNMTFb60rMUV9JEHFCmXkGpd2TOg3jr77bdJ4gnhfJlFvgh5de8BuJaZTJEcpzAk 6XpcugncRTE9VU/GEGhW3zaRC8Iba9vyl9Bgxhz8o8d1veA9wi7K2d9Ywo+Zj9cvYzgU D6NK5oG7yyaNT4ASqiM5I0FSxVT871UlYWPjnp3lAnjbdDu1f61z+VFAafO0gEmLA3pK d951z3IUy9wMfXCYFLeZj0x8zloxWeeWEsC4TRegHnH82G+FsvjwGcUaNwF1oZBfLryN nFvQ== X-Gm-Message-State: AOAM532KW04T9fsioPtxLXBIip6AYrs9DCuy2w80H+jQ4e3UIcsL46GH gYkrhaEWZNuaIEWteRBy/HlVuLs2VhrA0T/fK8nsDQJwcBWV9Q== X-Google-Smtp-Source: ABdhPJyYaXbZy+LzbWpeXvAqEXpNb7VBUwCXylmPpi/oHEUljqcTjbXi95Lpass4QrUvYrPjXmjFmxVSijB7pWNETA8= X-Received: by 2002:ac8:594c:: with SMTP id 12mr12054432qtz.224.1607120831395; Fri, 04 Dec 2020 14:27:11 -0800 (PST) MIME-Version: 1.0 From: Todd Herr Date: Fri, 4 Dec 2020 17:26:55 -0500 Message-ID: To: IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000445b0a05b5aafaf2" Archived-At: Subject: [dmarc-ietf] Ticket #85 - New Description for 'p' tag and values X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 04 Dec 2020 22:27:15 -0000 --000000000000445b0a05b5aafaf2 Content-Type: text/plain; charset="UTF-8" In the "Ticket #39" thread, Dave Crocker asserted the following about the 'p' tag and its values: "The premise that an author domain owner can, in any way, direct the message disposition decisions of a receiving system is simply false. It's false to a level of silliness, if one adequately considers the complete independence of the receiver from the domain owner. The domain owner can, perhaps, express something about the owner's own concerns for mail that fails dmarc, but that's different from saying anything about the receiver's decisions about how to respond to those expressed concerns. That is, the language expressing the semantics should be changed to be, in a sense, egocentric. How do I, the domain owner feel about (assess) the meaning of a DMARC failure?" Later in that same thread, he proposed the following as possible new language for the description of the 'p' tag and values in section 6.3: *p*: Domain Owner Assessment Policy (plain-text; REQUIRED for policy records). Indicates the severity of concern the domain owner has, for mail using its domain but not passing DMARC validation. Policy applies to the domain queried and to subdomains, unless subdomain policy is explicitly described using the "sp" tag. This tag is mandatory for policy records only, but not for third-party reporting records (see Section 7.1 ). Possible values are as follows: *none*: The Domain Owner offers no expression of concern. *quarantine:* The Domain Owner considers such mail to be suspicious. It is possible the mail is valid, although the failure creates a significant concern. *reject: *The Domain Owner considers all such failures to be a clear indication that the use of the domain name is not valid. See Section 10.3 for some discussion of SMTP rejection methods and their implications. I believe this to be worthy of its own dedicated ticket and discussion, and so have created a ticket specifically for it. -- *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. --000000000000445b0a05b5aafaf2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
In the "Ticket #39" thread, Dave Crocker asserte= d the following about the 'p' tag and its values:

"The premise that an = author domain owner can, in any way, direct the
message disposition decisions of a recei= ving system is simply false.
It's false to a level of silliness, if one adequately c= onsiders the
= complete independence of the receiver from the domain owner.

concerns fo= r mail that fails dmarc, but that's different from saying
anything about the receive= r's decisions about how to respond to those
expressed concerns.

That is, the language expressing the semantics should b= e changed to be, in a sense, egocentric. How do I, the domain owner feel ab= out (assess) the meaning of a DMARC failure?"


Later in that same thread, he proposed the following as po= ssible new language for the description of the 'p' tag and values i= n section 6.3:

p: Domain Owner Assessment Poli= cy (plain-text; REQUIRED for policy records). Indicates the severity of con= cern the domain owner has, for mail using its domain but not passing DMARC = validation. Policy applies to the domain queried and to subdomains, unless = subdomain policy is explicitly described using the "sp" tag. This= tag is mandatory for policy records only, but not for third-party reportin= g records (see=C2=A0Section 7.1). Possible values are as follows:

none: The Domain Owner offers no expression of conce= rn.

quarantine:=C2=A0The Domain Owner considers such mail = to be suspicious. It is possible the mail is valid, although the failure cr= eates a significant concern.

reject:=C2=A0The Domain Owner con= siders all such failures to be a clear indication that the use of the domai= n name is not valid.=C2=A0 See=C2=A0Section 10.3=C2=A0for some disc= ussion of SMTP rejection methods and their implications.


I believe this to be worthy of its own dedicated ticket and di= scussion, and so have created a ticket specifically for it.

--

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


This email and all data transmitt= ed with it contains confidential and/or proprietary information intended so= lely 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, di= sclosure, copying or distribution of the information included in this trans= mission is prohibited and may be unlawful. Please immediately notify the se= nder by replying to this email and then delete it from your system.<= /font>

--000000000000445b0a05b5aafaf2-- From nobody Fri Dec 4 14:28: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 8191F3A0D93 for ; Fri, 4 Dec 2020 14:28:12 -0800 (PST) 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 5yt81oRQRXDq for ; Fri, 4 Dec 2020 14:28:10 -0800 (PST) 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 9F5343A0EE6 for ; Fri, 4 Dec 2020 14:28:10 -0800 (PST) Received: by mail-vs1-xe33.google.com with SMTP id w18so4124692vsk.12 for ; Fri, 04 Dec 2020 14:28:10 -0800 (PST) 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=PKRPep5YS54uIjQt4BnuzWezYFSSkQbqfbawjfusnQI=; b=RxrVo7/xkPgcX/V4ICBrZBZhuqhNgDhNjD29IhkHK8KxbD9o4JmBHuo7NHCpwdUM/7 Y+amLAEd2URapweb7BwzWKeF0yLl7SQixMwO2hqIBDEGW0Pe0dN6nHuGmSft1UlZ6ENH kxdv47zxK1YAE0Q8t7JJn0BkL/KoosXhscQO5jR7R4se3qCVkHwMJRoZ8GQ7tI5Ho9rU PB0aV/iukyddELHhur2TZUMT5QrYksN+jfZ2uF0h/NWMlBSfsJfbKdDOK+C7tEQZPWEh O+tmOil8WTHShUB1mJ90RHQnBSHYoBcUwmlVtsxAVZgWpGMkrDxHzQ9VeFoSk+1pzpRX M/tw== 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=PKRPep5YS54uIjQt4BnuzWezYFSSkQbqfbawjfusnQI=; b=n3azEZWJgfXlnWhdA1on//7FPEY2xHI7k2HhWm3bj1jvSSGUxgZ1KKNPWGP6W91C1r mdPfUWJUaE1pfkZv6T0dMjfwPV5jWGhnMnuzEylwkuvyGQuprYaTZ3Acy4d1UvKyVlJU QcY3uuYtG8xABS8EHYozFSQrq+/SwL/0ugOKt7QIztT2j/PRmx+nT9YteBrCIZmpP7IC v5OTvFzhUNI2yE9tXCgUy3cSgtF9RGgPD3AoUIln36+JyDX+lE15aLNfx4VSU5bqVfzw YoN2Sx3psLQgMDIP2XgOdl7SoWOfULGTRQXkWMUG5JA5T+o+ocvNFvT/2uYmyj4eYLQB FpsA== X-Gm-Message-State: AOAM532rARgfXUmoSFMHoGZ89TlFNVDp1es4sx5h5JXW4PoXRRVoxOUx WCiekvzA/AIA9x28lP9zHdte03icmGL+vuQyefKS+VKXYWlN X-Google-Smtp-Source: ABdhPJzHKsotwkCTkAGS9UuBlmiigXf9J47e1//AMbMgoycvERQXoxDUsT0W/L1fCTCOw4BG+x2KUBVrr8cs1hvHcuk= X-Received: by 2002:a67:e90d:: with SMTP id c13mr6133166vso.0.1607120889433; Fri, 04 Dec 2020 14:28:09 -0800 (PST) MIME-Version: 1.0 References: <134860ee-5fbf-2fb3-a5b3-4be68806ab22@mtcc.com> In-Reply-To: <134860ee-5fbf-2fb3-a5b3-4be68806ab22@mtcc.com> From: Brandon Long Date: Fri, 4 Dec 2020 14:27:57 -0800 Message-ID: To: Michael Thomas Cc: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="000000000000ba2edf05b5aafd9d" Archived-At: Subject: Re: [dmarc-ietf] is DMARC informational? X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 04 Dec 2020 22:28:13 -0000 --000000000000ba2edf05b5aafd9d Content-Type: text/plain; charset="UTF-8" The DMARC spec was originally designed by folks outside of IETF, and the current RFC was a "cleaned up" and modified into RFC format version of that spec, to match current practice. There was also concern with the spec's impact on various indirect email. Hence, informational and independent submission. This is somewhat spelled out in the working group charter: https://datatracker.ietf.org/wg/dmarc/about/ Brandon On Fri, Dec 4, 2020 at 1:41 PM Michael Thomas wrote: > > Is my google fu completely failing me, or is RFC 7489 not the DMARC > protocol spec? > > If it's informational, how did that happen? > > Mike > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > --000000000000ba2edf05b5aafd9d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The DMARC spec was originally designed by folks outside of= IETF, and the current RFC was a "cleaned up" and modified into R= FC format version of that spec, to match current practice.
There was al= so concern with the spec's impact on various indirect email.
=

Hence, informational and independent submission.

This is somewhat spelled out in the working group charter:=C2=A0https://datatracker.i= etf.org/wg/dmarc/about/

Brandon

On = Fri, Dec 4, 2020 at 1:41 PM Michael Thomas <mike@mtcc.com> wrote:

Is my google fu completely failing me, or is RFC 7489 not the DMARC
protocol spec?

If it's informational, how did that happen?

Mike

_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
--000000000000ba2edf05b5aafd9d-- From nobody Fri Dec 4 14:38: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 3CF9D3A0EE6 for ; Fri, 4 Dec 2020 14:38:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.651 X-Spam-Level: X-Spam-Status: No, score=-1.651 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, 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=mtcc-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dtb0WlMkxN5d for ; Fri, 4 Dec 2020 14:38:56 -0800 (PST) Received: from mail-pj1-x1035.google.com (mail-pj1-x1035.google.com [IPv6:2607:f8b0:4864:20::1035]) (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 E13873A0D85 for ; Fri, 4 Dec 2020 14:38:55 -0800 (PST) Received: by mail-pj1-x1035.google.com with SMTP id lb18so1446617pjb.5 for ; Fri, 04 Dec 2020 14:38:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mtcc-com.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=teZrDUm+4YQA+QJGCAXreexZVW84/np66Ehm2BiGw5A=; b=RJdTq1pTUe0uq1yfHKdzoH2cPc/BHykjpJr+FhF0v4D1oXD+I8Fo99cfV3uOuKwhsn uuPHBgph02lfC5ML26NfviXRVOJG1cqVindJY1QHCGUYXOrEbB9GXwjubtAuoy6WoOQR 6yLo09FBpg2n6rJcm1JEv6NGgQliEGs0SVitnfilCFSJwZ2zrkJM/UOOJ76ZwbxYyVS6 5Uy9+PwDSAJ/LrTyjZTQ5wL/y6+TPN6IWO0pKHe1KA1ldsqZ4AhXQtHc4Zw9FxlwAspf JfYI9ACEqgLUv7oFBwOMjAPeLjTO+qe/TOp+TzL5cHv+rAxq4hKYizocIkDryaZVNxmk qgmg== 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=teZrDUm+4YQA+QJGCAXreexZVW84/np66Ehm2BiGw5A=; b=KX6x+8FZAPM6QDrAKcjRklIKIMMyPhBnqZVZ+nc6v+SJ+sJeNf5P+SXsjtKa1BZKlA Mt5m3ZGFnbvPEard5mESt03q7JAbPvKLsN9I5ihQP2AJkId4Z73S1+TZGuDpfbWhwqI/ 7xBG7yxEmYpkqzNnHrxfHpj4cjhfY6G3n2xcc+XTSkFYQe9pNyIEaklOd0GCmbzwOVAN cxCUStjYYkWEKguoee99kTI7V30i9TFL4qGk5/abkX7rHEqZ+qMD4SKmbV/MHpsC+vt1 D5f6YVGiuAc3hjEVuax6EnjSsrHHZm9FI4d3mpBEbbIc//JbxtiyU37luZlxYHzz88/+ VbzQ== X-Gm-Message-State: AOAM530d4Td2M+8wwkeyLITiZ5HEUMmjndWgWk//tREMrKGJ7jWCsra8 lUicFWMvppJn1xOXOlw9P7ANQMDysCXNug== X-Google-Smtp-Source: ABdhPJxSEHYnL8pHpct7nI5vs1Clw17bhxSE0uhAnYGwlCmJy2seryIsk+sHzagTVeXdrRYoIsq3Hw== X-Received: by 2002:a17:902:ea8c:b029:d6:e179:2097 with SMTP id x12-20020a170902ea8cb02900d6e1792097mr5708856plb.70.1607121533437; Fri, 04 Dec 2020 14:38:53 -0800 (PST) Received: from mike-mac.lan (107-182-42-33.volcanocom.com. [107.182.42.33]) by smtp.gmail.com with ESMTPSA id 199sm6142378pfb.219.2020.12.04.14.38.52 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 04 Dec 2020 14:38:52 -0800 (PST) To: Brandon Long Cc: "dmarc@ietf.org" References: <134860ee-5fbf-2fb3-a5b3-4be68806ab22@mtcc.com> From: Michael Thomas Message-ID: <7224575d-685f-5020-073e-c1880acecc88@mtcc.com> Date: Fri, 4 Dec 2020 14:38:51 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.5.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] is DMARC informational? X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 04 Dec 2020 22:38:57 -0000 On 12/4/20 2:27 PM, Brandon Long wrote: > The DMARC spec was originally designed by folks outside of IETF, and > the current RFC was a "cleaned up" and modified into RFC format > version of that spec, to match current practice. > There was also concern with the spec's impact on various indirect email. > > Hence, informational and independent submission. > > This is somewhat spelled out in the working group charter: > https://datatracker.ietf.org/wg/dmarc/about/ > > That seems really strange because that pretty much describes DKIM as well, and it's very standards track. And adsp which dmarc made historic was standards track, and certainly had all of the same issues with mailing lists, etc. Mike From nobody Fri Dec 4 14:42: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 F22243A0EE6 for ; Fri, 4 Dec 2020 14:42:47 -0800 (PST) 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 M5_Kay1YNRUZ for ; Fri, 4 Dec 2020 14:42:39 -0800 (PST) Received: from mail-pf1-x42c.google.com (mail-pf1-x42c.google.com [IPv6:2607:f8b0:4864:20::42c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF5163A0D85 for ; Fri, 4 Dec 2020 14:42:39 -0800 (PST) Received: by mail-pf1-x42c.google.com with SMTP id q10so4778433pfn.0 for ; Fri, 04 Dec 2020 14:42:39 -0800 (PST) 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=aWqX1YN/p0MFRuwvMwk46I2zXrsO01lgL0fhMSfvIto=; b=WHKqynJ8vQUWH0HWzPa9beqYXtZea4uGEj3Vf78vPzHLYjreIlxvNxzvtObBeHY6ig IUwnKgi1MDr6EWgMS+iR1eb7/sBcH1sLN5/ZsyBrRn/WaXbWIsehPgzUMf1Tr70HdPdr As5NHyCDqZdftqhkK0Y/Huc36ALgit7g6mgox71Q22eWewGkrWSWShA8+QrRCfZnKXMj Q9aFP8oQewsRaqmf2uIAb5E3xVpfuqFHbTpfmNUc6ACwPn8P3T7COwqd1N+kO8NSCSnu 1gXChsaoCT0LF/ZIh06g/QXf2hDVxrX233XjgIJ5USLOYLewfOLcuWiJmTT85rmQAewA vUEw== 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=aWqX1YN/p0MFRuwvMwk46I2zXrsO01lgL0fhMSfvIto=; b=db1aNvA14ibfdhHSEHgI8vYfZZHgFw+RxANGiRn03XHGI94oLnMYKXMZcCj6m+tM+O WodznGLk+CM5P8JsjeO7PsppUW/HszohUCwkoa02x/iiHnx2LYD3zNYG6bjMvMD3nWF1 LPLjZA5tUFRxZnXKVqCExVuWl3k904BbcVdw3jpP3AzkCXWT7qT0LlUff77lGDdgPaXu UMruyp2ulosc4fZEN7rGAYKDMA1gbPM8k3sAPbqBfJYt4Fi5zzNHimvb+yHmvsqrCA2a Pf2X6gxvV09+6kWgrD3ODjBlzyK2bmdQorVbxoQNTzxwDrclJRvO7culbaT5vT/skxKZ 9ygA== X-Gm-Message-State: AOAM532D+eK2n14CTmiddnUzvTJh0gu5jVtpS6/GF9Sr0/CnO9CHWQzl 8fZg50Xb60vBEIWqjPLy6jndBzDjtzY= X-Google-Smtp-Source: ABdhPJxvHzAX/LJbWflKEFWnZXAuMCO6o1szfWbrsv09CiVYyas0IX+fI0pP6W73nlU+RCnnFdprcw== X-Received: by 2002:a62:ae01:0:b029:19d:b0e1:83c5 with SMTP id q1-20020a62ae010000b029019db0e183c5mr5916634pff.79.1607121759063; Fri, 04 Dec 2020 14:42:39 -0800 (PST) Received: from [192.168.0.109] (c-24-130-62-181.hsd1.ca.comcast.net. [24.130.62.181]) by smtp.gmail.com with ESMTPSA id gj15sm3130205pjb.9.2020.12.04.14.42.38 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 04 Dec 2020 14:42:38 -0800 (PST) To: Michael Thomas , Brandon Long Cc: "dmarc@ietf.org" References: <134860ee-5fbf-2fb3-a5b3-4be68806ab22@mtcc.com> <7224575d-685f-5020-073e-c1880acecc88@mtcc.com> From: Dave Crocker Message-ID: <7e459496-61f8-ddcd-713c-3b6be448090c@gmail.com> Date: Fri, 4 Dec 2020 14:42:37 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.5.1 MIME-Version: 1.0 In-Reply-To: <7224575d-685f-5020-073e-c1880acecc88@mtcc.com> Content-Type: multipart/alternative; boundary="------------20C6B263C794B00EC93B3B64" Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] is DMARC informational? X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 04 Dec 2020 22:42:48 -0000 This is a multi-part message in MIME format. --------------20C6B263C794B00EC93B3B64 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 12/4/2020 2:38 PM, Michael Thomas wrote: > That seems really strange because that pretty much describes DKIM as > well, and it's very standards track. And adsp which dmarc made > historic was standards track, and certainly had all of the same issues > with mailing lists, etc. DKIM did a version of the same thing, but with less time between publishing the non-IETF work and then having a working group to produce and IETF version: https://tools.ietf.org/html/rfc4870 vs. https://tools.ietf.org/html/rfc4871 Note the Obsoletes value. > Network Working Group E. Allman > Request for Comments: 4871 Sendmail, Inc. > Obsoletes:4870 J. Callas > Category: Standards Track PGP Corporation > M. Delany > M. Libbey > Yahoo! Inc > J. Fenton > M. Thomas > Cisco Systems, Inc. > May 2007 > > > > > DomainKeys Identified Mail (DKIM) Signatures > -- Dave Crocker dcrocker@gmail.com 408.329.0791 Volunteer, Silicon Valley Chapter American Red Cross dave.crocker2@redcross.org --------------20C6B263C794B00EC93B3B64 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
On 12/4/2020 2:38 PM, Michael Thomas wrote:
That seems really strange because that pretty much describes DKIM as well, and it's very standards track. And adsp which dmarc made historic was standards track, and certainly had all of the same issues with mailing lists, etc.

DKIM did a version of the same thing, but with less time between publishing the non-IETF work and then having a working group to produce and IETF version:

https://tools.ietf.org/html/rfc4870

vs.

https://tools.ietf.org/html/rfc4871

Note the Obsoletes value.

Network Working Group                                          E. Allman
Request for Comments: 4871                                Sendmail, Inc.
Obsoletes: 4870                                                J. Callas
Category: Standards Track                                PGP Corporation
                                                               M. Delany
                                                               M. Libbey
                                                              Yahoo! Inc
                                                               J. Fenton
                                                               M. Thomas
                                                     Cisco Systems, Inc.
                                                                May 2007

              
DomainKeys Identified Mail (DKIM) Signatures

-- 
Dave Crocker
dcrocker@gmail.com
408.329.0791

Volunteer, Silicon Valley Chapter
American Red Cross
dave.crocker2@redcross.org
--------------20C6B263C794B00EC93B3B64-- From nobody Fri Dec 4 14:45: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 30DD43A0FF0 for ; Fri, 4 Dec 2020 14:45:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.65 X-Spam-Level: X-Spam-Status: No, score=-1.65 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mtcc-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p_2fhrfrp5Eo for ; Fri, 4 Dec 2020 14:45:18 -0800 (PST) Received: from mail-pf1-x42e.google.com (mail-pf1-x42e.google.com [IPv6:2607:f8b0:4864:20::42e]) (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 948D83A0FF5 for ; Fri, 4 Dec 2020 14:45:18 -0800 (PST) Received: by mail-pf1-x42e.google.com with SMTP id t7so4767693pfh.7 for ; Fri, 04 Dec 2020 14:45:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mtcc-com.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=myy/KrriTz5JcBG7W43rBmhMpkaSf0h+XfPsc05zNjY=; b=AZ/ZAuQqAbn1jco9bAgkSZbU08KBhTosiRFZoWDnsZy2E7UtAL20Z2+r+Gnjzn0JK9 oxmhHCuWVsnQxwz1+/2hcFOR0vV4aJTghBZfgGRtTzPWrzbZVDF5whdUdvfb+HeXC3CS oE7n9p/z9/FbftBW9UyInBUdsu7V4UBeNJEEdJRauByISgu55o5JndQVCFkilOqinVu4 On23MZHnqtoMws2Vs6zh5ploi6obVOGlDns5iIBEkw5GbxbQX9GkzAKAiC1DcDckEBHJ awaRLsSO3I7L0kovaSeBkqJa3Q9wik1/77SD8sUtTJdABc7budZo+4CAtvvNF3sGR3Rx Jkng== 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=myy/KrriTz5JcBG7W43rBmhMpkaSf0h+XfPsc05zNjY=; b=goF8B28taMmTLEjhVSuSk7LkSr9mlfBqSETgb1HgO3mES/5EcS52tMWcmASukNvCVH yKm3utOmIBtXWnAwBL5ttad+2Ehg9xBZsslNRyZi/A4vK4EPrhKDcfl43vlOvaW29MvU 0iRSxvnm/IBZqmKp8YZBsWNPV1v++iE1d4qHdi1V8cYzc24Ssx7CGN5EuBmIO06MF3vQ uKPKWGRx7QRC78Uj/GFwvJEzc/9Z0IIR40Fp5RgwQqhbTLnRhor/+9Wo8R2LCoQgbIVi nX1GlEva/fMAj7LFPJJRN5oMYowFoonhj5GmqbooO5ffDMFX9GL6Zgytu7MfLuL7w+nK v5Uw== X-Gm-Message-State: AOAM532xJnZLBXAiQalNLjsnUJ99ZkXeP3rDmusAESBdXLKww3QgCYT7 0oRgbWNSXDhuDl4Z1A/zm/fDND+XZ+wRFg== X-Google-Smtp-Source: ABdhPJw59v4UuYItyIfBgQ3F6g9iKB3iRz428A/om0Urm8cto4sOW/VvGvWEv4XIrLWBAvzC8PTYRQ== X-Received: by 2002:a63:1422:: with SMTP id u34mr626277pgl.153.1607121917584; Fri, 04 Dec 2020 14:45:17 -0800 (PST) Received: from mike-mac.lan (107-182-42-33.volcanocom.com. [107.182.42.33]) by smtp.gmail.com with ESMTPSA id s15sm4732576pga.43.2020.12.04.14.45.16 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 04 Dec 2020 14:45:17 -0800 (PST) To: Dave Crocker , Brandon Long Cc: "dmarc@ietf.org" References: <134860ee-5fbf-2fb3-a5b3-4be68806ab22@mtcc.com> <7224575d-685f-5020-073e-c1880acecc88@mtcc.com> <7e459496-61f8-ddcd-713c-3b6be448090c@gmail.com> From: Michael Thomas Message-ID: <2cecceac-1add-44ec-6e16-e157fee293fe@mtcc.com> Date: Fri, 4 Dec 2020 14:45:15 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 MIME-Version: 1.0 In-Reply-To: <7e459496-61f8-ddcd-713c-3b6be448090c@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] is DMARC informational? X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 04 Dec 2020 22:45:20 -0000 On 12/4/20 2:42 PM, Dave Crocker wrote: > On 12/4/2020 2:38 PM, Michael Thomas wrote: >> That seems really strange because that pretty much describes DKIM as >> well, and it's very standards track. And adsp which dmarc made >> historic was standards track, and certainly had all of the same >> issues with mailing lists, etc. > > DKIM did a version of the same thing, but with less time between > publishing the non-IETF work and then having a working group to > produce and IETF version: > > https://tools.ietf.org/html/rfc4870 > > vs. > > https://tools.ietf.org/html/rfc4871 > > yes, but the new version was standards track. that's what i'm finding surprising. Mike From nobody Fri Dec 4 14:46: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 32BCB3A0FF3 for ; Fri, 4 Dec 2020 14:46:03 -0800 (PST) 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 xGBr_iygkgoM for ; Fri, 4 Dec 2020 14:46:01 -0800 (PST) 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 37F8F3A0FF0 for ; Fri, 4 Dec 2020 14:46:01 -0800 (PST) Received: by mail-ua1-x92f.google.com with SMTP id t15so2399658ual.6 for ; Fri, 04 Dec 2020 14:46:01 -0800 (PST) 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=pPE3lszSgH4HavNbe1MMQlb8qKJYi+RJ0EId68pRjjU=; b=Rl1KVdp8DdnRcgy9+BF/0g0hIrim4Ywv8LFrn69Q/Kr58IfCgmE7kSMAytyk4sZ5fq hVFZh8av5BFFBUjuSad9CGYM+i1C50lPe0I+XqX5NdsZX9VTn4RsOfE0krmWTjGLxDT/ 8shGH18OsyUcSxoviDlI4sqPlN9hYvhFcxsC+GFpWveCviqiGZtsUWwMWZGYhI2Rfzaz 6M1srSoF3ztDl6CduKXdYxXQYl4BiaitlPqUwwntk5prUYGREJ9pVs2oJbLkNEmE9Z/T Yz8wYvfkq2dYHCAU23/f4ekgzmWurW8I1RbAc//1A8CiEaA5Z1qhbfUtOScWviNczWqY FMdQ== 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=pPE3lszSgH4HavNbe1MMQlb8qKJYi+RJ0EId68pRjjU=; b=R1shUVFpyTxr5e3FNxGmx4sMZpgtpojSKLbKDV8ik2UcKF+HNNJ3fRUbiH3vbgsIGj YjAmtnVfXOPJeNgMScV890+D0y1drmE5DWZ8PpuZfE0lsgwTEwVn16Iae7chQFdKDzfY bTbAo+32/n5AEqAcOvXEwE0wn/l6xcSxis5Kp88jEGDtyBqs0wWpXwkcr7mrfPOfTQ/L x90q5OD0nhC9rJpruqYoLNOBHMOfY6jCA7iZM/8yovMM9J7sKEryHERPE25jZmux/Zfx qGA8KvvnzaHBQ8/eaC1q1zIwVdK198V2r9Z/DiVyViM4DLSx5bbrgEUQ9L9LV2qR3So7 magA== X-Gm-Message-State: AOAM530MTjOztPZy/EpOkfE4+7xRDQOMQBscBbvr5/w8K3rLRcc7noDz 3soGEiCazEYuMFwPaScWK6v9W486xPKvdiAff2+aFNYdtw== X-Google-Smtp-Source: ABdhPJyZ1OB9WxI3CSKE+xCwxM2n7P+KG3+g8aDhr60RmBFgVtzZs+rMkWylL15NOB6JklD8bLipuYfxK6b1rBK3ihU= X-Received: by 2002:ab0:2c05:: with SMTP id l5mr6012044uar.40.1607121959899; Fri, 04 Dec 2020 14:45:59 -0800 (PST) MIME-Version: 1.0 References: <8c83fffc-077d-9ddb-db2f-b9763361c60f@tana.it> <39eafc5e-3d9c-0bea-1173-7277070195ea@wisc.edu> <081c42a3-492b-89b7-ad76-ccec48dea091@tana.it> <2d1dca4f-e46a-646c-9fa3-d9ca56c72196@tana.it> <01d1849f-6a0a-5307-db54-7587e33fc018@tana.it> In-Reply-To: <01d1849f-6a0a-5307-db54-7587e33fc018@tana.it> From: Brandon Long Date: Fri, 4 Dec 2020 14:45:47 -0800 Message-ID: To: Alessandro Vesely Cc: IETF DMARC WG Content-Type: multipart/alternative; boundary="00000000000088413405b5ab3d34" Archived-At: Subject: Re: [dmarc-ietf] A policy for direct mail flows only, was ARC questions X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 04 Dec 2020 22:46:03 -0000 --00000000000088413405b5ab3d34 Content-Type: text/plain; charset="UTF-8" On Wed, Dec 2, 2020 at 3:11 AM Alessandro Vesely wrote: > On Wed 02/Dec/2020 03:14:46 +0100 Brandon Long wrote: > > On Tue, Dec 1, 2020 at 2:37 AM Alessandro Vesely wrote: > >> On Tue 01/Dec/2020 05:56:46 +0100 Brandon Long wrote: > >>> On Thu, Nov 26, 2020 at 12:59 AM Alessandro Vesely > wrote: > >>>> On 25/11/2020 20:16, Michael Thomas wrote: > >>>>> On 11/25/20 11:11 AM, Alessandro Vesely wrote: > >>>>>> On 25/11/2020 19:24, Jesse Thompson wrote: > >>>>>>> On 11/25/20 11:30 AM, Alessandro Vesely wrote: > >>>>>>>> Without resorting to ARC, it is still possible to validate author > >>>>>>>> domain's signatures directly if the MLM just adds a subject tag > >>>>>>>> and a footer>>>>> > >>>>>>> I agree that ARC isn't really needed to do this (trust the last hop > >>>>>>> from the MLM and determine the original authenticity from the MLM's > >>>>>>> perspective)>>>> > >>>>>> I didn't mean to trust the MLM. I meant remove the subject tag and > >>>>>> the footer, then the original DKIM signature verifies. See: > >>>>>> https://datatracker.ietf.org/doc/draft-vesely-dmarc-mlm-transform/ > >>>>> > >>>>> When I was at Cisco, with l= and some subject line heuristics I > could get > >>>>> probably like 90+% verification rate across the entire company, a > company that > >>>>> uses external mailing lists a lot. Definitely not 100% though. > >>>> > >>>> > >>>> DKIM itself is not 100%. You always have lines beginning with "From > " or > >>>> occasional autoconversions. > >>>> > >>>> l= doesn't cover multipart/alternative nor Content-Transfer-Encoding: > >>>> base64. In addition, the DKIM spec discourages its usage and suggests > >>>> that "Assessors might wish to ignore signatures that use the tag.">> > >>> > >>> Right, some of the other dkim-light or diff concepts we discussed > would be > >>> better than using l= > >>> > >>> We again got hung up on the 100% solution, though... something that > handled > >>> subject-prefix and footer in a transport agnostic way might have > worked. > >> > >> I'm not clear about the meaning of "100%". If an author domain puts no > >> DKIM signatures, there is no way to verify them. Hence, some > compliance of > >> the author domain has to be required. > >> > >> The same holds for conditional signatures. > >> > >> The same holds for MLM transformations. > >> > > > > Yes, by 100% I meant of messages that were already authenticated and > > therefore should continue to be authenticated through the relay. > > That's ARC. If a message lacks DKIM and was SPF-authenticated, there's no > way > it can continue to be authenticated through a relay. > > OTOH, mailing lists and relays are two different beasts. For one thing, > it is > very unusual for a mailing list to send to another mailing list. Thus, we > can > safely specify a non-stackable authentication method. > mailing list to mailing list mail is very common in GSuite, but maybe we're a special case. Part of that was that aliases were moved to the mailing list infra (which is definitely more of an "our problem" than everyone), but we also see common usage where companies make groups matching their hierarchy (the all company group goes to all department groups which go to all local groups etc). We also see some where announce groups mix contrib groups, etc. Especially since we also use the same groups as ACL groups for GSuite and Google Cloud, so hierarchical groups are very common. (there was a recent common where someone said who needs an org chart when we have email, showing the list of footers for all of the org level mailing lists the message went to to get to them) (one construction of hierarchical announce lists that was not well considered did result in every person on the combined list getting 9000 copies of messages to the list, so flattening lists is sometimes much preferred) Which isn't to say we couldn't work around it or do the work to flatten the lists, though it increases the complexity of the product (can you unsubscribe from the top level list but not a sub list?) Brandon --00000000000088413405b5ab3d34 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Dec 2, 2020 at 3:11 AM Alessa= ndro Vesely <vesely@tana.it> wr= ote:
On Wed 02/D= ec/2020 03:14:46 +0100 Brandon Long wrote:
> On Tue, Dec 1, 2020 at 2:37 AM Alessandro Vesely <vesely@tana.it> wrote:
>> On Tue 01/Dec/2020 05:56:46 +0100 Brandon Long wrote:
>>> On Thu, Nov 26, 2020 at 12:59 AM Alessandro Vesely <vesely@tana.it> wrote:<= br> >>>> On 25/11/2020 20:16, Michael Thomas wrote:
>>>>> On 11/25/20 11:11 AM, Alessandro Vesely wrote:
>>>>>> On 25/11/2020 19:24, Jesse Thompson wrote:
>>>>>>> On 11/25/20 11:30 AM, Alessandro Vesely wrote:=
>>>>>>>> Without resorting to ARC, it is still poss= ible to validate author
>>>>>>>> domain's signatures directly if the ML= M just adds a subject tag
>>>>>>>> and a footer>>>>>
>>>>>>> I agree that ARC isn't really needed to do= this (trust the last hop
>>>>>>> from the MLM and determine the original authen= ticity from the MLM's
>>>>>>> perspective)>>>>
>>>>>> I didn't mean to trust the MLM.=C2=A0 I meant = remove the subject tag and
>>>>>> the footer, then the original DKIM signature verif= ies.=C2=A0 See:
>>>>>> https://d= atatracker.ietf.org/doc/draft-vesely-dmarc-mlm-transform/
>>>>>
>>>>> When I was at Cisco, with l=3D and some subject line h= euristics I could get
>>>>> probably like 90+% verification rate across the entire= company, a company that
>>>>> uses external mailing lists a lot. Definitely not 100%= though.
>>>>
>>>>
>>>> DKIM itself is not 100%.=C2=A0 You always have lines begin= ning with "From " or
>>>> occasional autoconversions.
>>>>
>>>> l=3D doesn't cover multipart/alternative nor Content-T= ransfer-Encoding:
>>>> base64. In addition, the DKIM spec discourages its usage a= nd suggests
>>>> that "Assessors might wish to ignore signatures that = use the tag.">>
>>>
>>> Right, some of the other dkim-light or diff concepts we discus= sed would be
>>> better than using l=3D
>>>
>>> We again got hung up on the 100% solution, though... something= that handled
>>> subject-prefix and footer in a transport agnostic way might ha= ve worked.
>>
>> I'm not clear about the meaning of "100%".=C2=A0 If = an author domain puts no
>> DKIM signatures, there is no way to verify them.=C2=A0 Hence, some= compliance of
>> the author domain has to be required.
>>
>> The same holds for conditional signatures.
>>
>> The same holds for MLM transformations.
>>
>
> Yes, by 100% I meant of messages that were already authenticated and <= br> > therefore should continue to be authenticated through the relay.
That's ARC.=C2=A0 If a message lacks DKIM and was SPF-authenticated, th= ere's no way
it can continue to be authenticated through a relay.

OTOH, mailing lists and relays are two different beasts.=C2=A0 For one thin= g, it is
very unusual for a mailing list to send to another mailing list.=C2=A0 Thus= , we can
safely specify a non-stackable authentication method.
=
mailing list to mailing list mail is very common in GSuite, = but maybe we're a special
case.=C2=A0 Part of that was that a= liases were moved to the mailing list infra (which is definitely
= more of an "our problem" than everyone), but we also see common u= sage where=C2=A0
companies make groups matching their hierarchy (= the all company group goes to
all department groups which go to a= ll local groups etc).=C2=A0 We also see some where
announce group= s mix contrib groups, etc.=C2=A0 Especially since we also use the same
groups as ACL groups for GSuite and Google Cloud, so hierarchical gro= ups are very
common.

(there was a recent= common where someone said who needs an org chart when we
have em= ail, showing the list of footers for all of the org level mailing lists the= message
went to to get to them)

(one co= nstruction of hierarchical announce lists that was not well considered did = result
in every person on the combined list getting 9000 copies o= f messages to the list, so=C2=A0
flattening lists is sometimes mu= ch preferred)

Which isn't to say we couldn'= ;t work around it or do the work to flatten the lists, though
it = increases the complexity of the product (can you unsubscribe from the top l= evel list=C2=A0
but not a sub list?)

Bra= ndon
--00000000000088413405b5ab3d34-- From nobody Fri Dec 4 14:49: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 20C453A1142 for ; Fri, 4 Dec 2020 14:49:13 -0800 (PST) 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 f89i3ivfqlUk for ; Fri, 4 Dec 2020 14:49:11 -0800 (PST) Received: from mail-pf1-x42a.google.com (mail-pf1-x42a.google.com [IPv6:2607:f8b0:4864:20::42a]) (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 EDD253A1172 for ; Fri, 4 Dec 2020 14:49:01 -0800 (PST) Received: by mail-pf1-x42a.google.com with SMTP id o9so4761124pfd.10 for ; Fri, 04 Dec 2020 14:49:01 -0800 (PST) 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=ybdtfrHSyGJgE8scT/9OS7DBOlzOTadc/5DHv9y/eq4=; b=IwSH8RrI5LEY4qobnDKT+VXVgNFj8zYq53R/+y/iPPBqdFXSKUWj12WUVNqIbcNgGb ixdMwbQXXzTmljPQ2d2eB27zTFg9EiSt2oxBXUvEdBRzRIq51E4GuqL8e0G3loNNQ8Rc S1ku/OfqBDzJK5BWQQvDftCG6BLsES7GOZ7BoVV0HYb5yQYxELLUadUTpQtOIfyv4E3K 92JpuqOloKa3uJUINNaLtoRDtgsGkwXrWLwGZqGpKhu+zY7ffhYLj7iE1f0JuF13d408 Ct0mZXcHvbiwj7wOZ4TWuQ3MqJZwZs08k915/0tnt5xdFUw8e/jHMqNpFFuG4vdsUV8F XtPQ== 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=ybdtfrHSyGJgE8scT/9OS7DBOlzOTadc/5DHv9y/eq4=; b=KMctGkTradAQ1f4Gf/zha0O75hDkqjStN6fp06299QHOkukIUWSQnbJQJtiFrzipXe 3fyDsb/qwgZN7Dfi5Rk2LNbIPWlYpE+uqA+EoGCjJvA81OVmi0jeVKi1vQT3AqTyyJtV aJT/iMoVPia1PXuuDx3i9Yua7UI6QL87LNGnOWgvupViQJJGbwYTsEB0affp3g3LK6Da fXxr4yAGrNeX8CW+KlJ/NL9m/gqW/23ORNmK4mTWv8bXCoUFJU2DdYIrw25GZ41WD8gZ gzSYlNWYQ8hgJ6eBzV7iO0Nkx/oWwHLZAEw8hetQtDxZWa6czu6Xqfcz1VZQsbkecFA8 4RCg== X-Gm-Message-State: AOAM533EQ9VRv7wtfegCqv2nP5dRRqQBO1BGxBGFStuoeRNUQyry0xV6 IJi+gaI51z4xJLYj0iAIgE5nVCliV3Q= X-Google-Smtp-Source: ABdhPJwOfhk9r8ajIo+JEl/WCFOFlbseekzkIJH7Xtu3tCsiKElixaf0dBHfKEktW0b7QwOrVWlITQ== X-Received: by 2002:a62:f20e:0:b029:197:f6d8:8d4d with SMTP id m14-20020a62f20e0000b0290197f6d88d4dmr5828793pfh.58.1607122141318; Fri, 04 Dec 2020 14:49:01 -0800 (PST) Received: from [192.168.0.109] (c-24-130-62-181.hsd1.ca.comcast.net. [24.130.62.181]) by smtp.gmail.com with ESMTPSA id 3sm6149355pfh.166.2020.12.04.14.49.00 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 04 Dec 2020 14:49:00 -0800 (PST) To: Michael Thomas , Brandon Long Cc: "dmarc@ietf.org" References: <134860ee-5fbf-2fb3-a5b3-4be68806ab22@mtcc.com> <7224575d-685f-5020-073e-c1880acecc88@mtcc.com> <7e459496-61f8-ddcd-713c-3b6be448090c@gmail.com> <2cecceac-1add-44ec-6e16-e157fee293fe@mtcc.com> From: Dave Crocker Message-ID: <5a577765-4a0d-e1bf-5321-dfeff19d107e@gmail.com> Date: Fri, 4 Dec 2020 14:48:59 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.5.1 MIME-Version: 1.0 In-Reply-To: <2cecceac-1add-44ec-6e16-e157fee293fe@mtcc.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] is DMARC informational? X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 04 Dec 2020 22:49:20 -0000 On 12/4/2020 2:45 PM, Michael Thomas wrote: > yes, but the new version was standards track. that's what i'm finding > surprising. Perhaps you should review the intended status for the current working group documents, such as dmarcbis: https://datatracker.ietf.org/wg/dmarc/documents/ d/ -- Dave Crocker dcrocker@gmail.com 408.329.0791 Volunteer, Silicon Valley Chapter American Red Cross dave.crocker2@redcross.org From nobody Fri Dec 4 14:51: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 710F33A0EE6 for ; Fri, 4 Dec 2020 14:51:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.651 X-Spam-Level: X-Spam-Status: No, score=-1.651 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, 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=mtcc-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qv-wAJWb8S4l for ; Fri, 4 Dec 2020 14:51:39 -0800 (PST) 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 391F13A0EA7 for ; Fri, 4 Dec 2020 14:51:39 -0800 (PST) Received: by mail-pg1-x52d.google.com with SMTP id t3so4416991pgi.11 for ; Fri, 04 Dec 2020 14:51:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mtcc-com.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=ASZvmC3Xg3Bg7jCexDBIb/EtnKD5cq7iiTNU2SZmtDU=; b=lTZB3YHSFQwENUI7aHtIdMomqfKp+pdnGV1iEGNZlIfr9YPfpnt2TEJ3sZS0+xboXH Lpk5km1NQ8g4o9lDdBnesjGd1p1JMM0YSNcXw6bPItpLmACAYCIVSidiPj7hJHDcPHxz rlURanxoKCBZPHcDprde4rcSDGvGLpQ5lK0KG9yfYBDZh3iZVxy9IPVJznEMrTsXZCFy oidQmTdLSqvy306u5kQLw0EWUwBzY40gfuuK43KKgQLY62TmkSnPYHO5rSRdnn6oKNk6 sq9Qc8XUOs2PfFY32Ikb5lrWmDqRP0blOgXD4eon26NzHbxNQrzGQ9qfbP/w6XZFf1A2 26TA== 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=ASZvmC3Xg3Bg7jCexDBIb/EtnKD5cq7iiTNU2SZmtDU=; b=lLixeG8kTsg586f+QeFUm9QXzaZBsGwH48oAHtJ5GqM8eSYGXAna8kSsEcV5lcmZoN mIMtpNaMIqWXow4bIKoBd43C13eguOvVq+BzakCp0znAuf5X2+yrtRNKpqW8qxxxtZ9Y hv1ydNZeB9wr4ESOwhB4VM2Lx6PLHx3AZzNg8z5YYQX3o1vG5ND5hnYZs0WihYTEKu0n /mPDjUNFA2e1cGVMefAFqymw74PiaNkjAqGuJVOZ0kNcl9aD7VvY1esUf2oj0LtsgXho ED+l0DtoH3kVGriYByFtRYeEEgsp4v7AZs4TCGuqCGhfb3wUxyvZRhXbyZ6nZN38ymYP ZhbA== X-Gm-Message-State: AOAM532+d8IGzx8RW8DeJYBQEO9KsAuFmvInIfL3FQh70AlFpFoLa+pB ksd6KUEt593luTuC0Xa0nYB+aF27253hxQ== X-Google-Smtp-Source: ABdhPJzvQ8JY2M6m0e3eZZM/InUD8WbFoLVb45dEArzcRoTXTuP1fYd1xicwsmVm5hbYU0ECJyXCnw== X-Received: by 2002:a63:5d42:: with SMTP id o2mr9342053pgm.69.1607122298310; Fri, 04 Dec 2020 14:51:38 -0800 (PST) Received: from mike-mac.lan (107-182-42-33.volcanocom.com. [107.182.42.33]) by smtp.gmail.com with ESMTPSA id s7sm4094716pfh.207.2020.12.04.14.51.37 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 04 Dec 2020 14:51:37 -0800 (PST) To: Dave Crocker , Brandon Long Cc: "dmarc@ietf.org" References: <134860ee-5fbf-2fb3-a5b3-4be68806ab22@mtcc.com> <7224575d-685f-5020-073e-c1880acecc88@mtcc.com> <7e459496-61f8-ddcd-713c-3b6be448090c@gmail.com> <2cecceac-1add-44ec-6e16-e157fee293fe@mtcc.com> <5a577765-4a0d-e1bf-5321-dfeff19d107e@gmail.com> From: Michael Thomas Message-ID: <40d7e78e-7026-c65c-383c-df4e3c537de3@mtcc.com> Date: Fri, 4 Dec 2020 14:51:36 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 MIME-Version: 1.0 In-Reply-To: <5a577765-4a0d-e1bf-5321-dfeff19d107e@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] is DMARC informational? X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 04 Dec 2020 22:51:41 -0000 On 12/4/20 2:48 PM, Dave Crocker wrote: > On 12/4/2020 2:45 PM, Michael Thomas wrote: >> yes, but the new version was standards track. that's what i'm finding >> surprising. > > Perhaps you should review the intended status for the current working > group documents, such as dmarcbis: > > https://datatracker.ietf.org/wg/dmarc/documents/ > What changed in the bis version to change its intended status? Mike From nobody Fri Dec 4 14:59: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 AA22E3A100D for ; Fri, 4 Dec 2020 14:59:48 -0800 (PST) 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 htY2QVCyPIPt for ; Fri, 4 Dec 2020 14:59:47 -0800 (PST) Received: from mail-pl1-x631.google.com (mail-pl1-x631.google.com [IPv6:2607:f8b0:4864:20::631]) (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 24CC23A1032 for ; Fri, 4 Dec 2020 14:59:47 -0800 (PST) Received: by mail-pl1-x631.google.com with SMTP id j1so3979480pld.3 for ; Fri, 04 Dec 2020 14:59:47 -0800 (PST) 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=TQjHZp6cQIdItcP3IWNsOOPeJ9+OlCMyjHctDQ5WXAA=; b=og0kSHb+dvW7YC9yxb/0AamLQmdOxx9joxbM9Ub0bgV9wAc42hQpF+KHcXf9GxSnFO 9flmJsuLR2/3y3Qw0IQjfq1uEzfSTJO9rwEJF7PnaKPs9Wazwg2uI8VMD2+d7jVxdZXX f3ooBczswsp1COopp6FGcaiKpgml+9eL++cyAfdJXzlmXZg6JEGT9G/5AJWM4QuyJAo7 UY4zJvbkPtfYYCtoGbVJ05ZKeDWkZA1+WEIaGyZZnk9YhZXTGnbexANhnyLDPQaIvwQO cnUsJhiu4jZ0YUtuU2a3zQG+PJzsmrXGQO8H8x1ohyQrCKtDYdCeqYzVuODWdhgpU6zr HDnw== 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=TQjHZp6cQIdItcP3IWNsOOPeJ9+OlCMyjHctDQ5WXAA=; b=lze+JlnFn+Hj7ZWVvxbRhiSGOZ2SMCkws/dbI1k0mEBL2qJlPV6xEg0GMTHKBebQUz Nr+8+yMU6MVWmUVzERkLlqRxUgzcvceA6FzajlxEWd0mY9iV/X554yBthnCB+gzx0DSi CXlDO2EpFcnvlT2UHH/Vp6I/CSqXsZP2ReurlwXK55BFraJEJ/Lykw5s0FcF3I9qVx+s Ksz4yRrvuzLwkOa9ZBug3nXthgBZ2z846MfvHlrmP80sFLzv/GSTTHrvGelCSRP8U23D MJj93DnRUUEzevCMzBcP8jN0wy74O9Swo0Dj8UPbcmIGz4VsvRHHIVG9deq3rxcqI/Pt g54Q== X-Gm-Message-State: AOAM532Om/cHX/s6CWfSSJCpKVExnqLacywPQbizJd9dTsySOEDozSaL uOAOubgUfEZiDo+kZcX9heLjsl6Q1rw= X-Google-Smtp-Source: ABdhPJw3i18KVq3QkpyIlbM2/MESWkhVhhSeEjv583B3U6+DR4BqCmw20yVBHc29raFKliXDA4xqiQ== X-Received: by 2002:a17:90a:7d08:: with SMTP id g8mr6100403pjl.180.1607122786439; Fri, 04 Dec 2020 14:59:46 -0800 (PST) Received: from [192.168.0.109] (c-24-130-62-181.hsd1.ca.comcast.net. [24.130.62.181]) by smtp.gmail.com with ESMTPSA id s6sm6253544pfh.9.2020.12.04.14.59.45 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 04 Dec 2020 14:59:45 -0800 (PST) To: Michael Thomas , Brandon Long Cc: "dmarc@ietf.org" References: <134860ee-5fbf-2fb3-a5b3-4be68806ab22@mtcc.com> <7224575d-685f-5020-073e-c1880acecc88@mtcc.com> <7e459496-61f8-ddcd-713c-3b6be448090c@gmail.com> <2cecceac-1add-44ec-6e16-e157fee293fe@mtcc.com> <5a577765-4a0d-e1bf-5321-dfeff19d107e@gmail.com> <40d7e78e-7026-c65c-383c-df4e3c537de3@mtcc.com> From: Dave Crocker Message-ID: <6fae9ca6-d8ea-1d62-4156-249191029cc3@gmail.com> Date: Fri, 4 Dec 2020 14:59:44 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.5.1 MIME-Version: 1.0 In-Reply-To: <40d7e78e-7026-c65c-383c-df4e3c537de3@mtcc.com> Content-Type: multipart/alternative; boundary="------------CE61089C4B620C23C8891AB2" Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] is DMARC informational? X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 04 Dec 2020 22:59:56 -0000 This is a multi-part message in MIME format. --------------CE61089C4B620C23C8891AB2 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 12/4/2020 2:51 PM, Michael Thomas wrote: >> https://datatracker.ietf.org/wg/dmarc/documents/ >> > What changed in the bis version to change its intended status? There is a 'History' button to click on that page, to answer that question. d/ -- Dave Crocker dcrocker@gmail.com 408.329.0791 Volunteer, Silicon Valley Chapter American Red Cross dave.crocker2@redcross.org --------------CE61089C4B620C23C8891AB2 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
On 12/4/2020 2:51 PM, Michael Thomas wrote:
https://datatracker.ietf.org/wg/dmarc/documents/

What changed in the bis version to change its intended status?

There is a 'History' button to click on that page, to answer that question.

d/

-- 
Dave Crocker
dcrocker@gmail.com
408.329.0791

Volunteer, Silicon Valley Chapter
American Red Cross
dave.crocker2@redcross.org
--------------CE61089C4B620C23C8891AB2-- From nobody Fri Dec 4 15:00: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 7AF903A1003 for ; Fri, 4 Dec 2020 15:00:33 -0800 (PST) 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 BRRm2-amUrgn for ; Fri, 4 Dec 2020 15:00:31 -0800 (PST) Received: from mail-il1-x131.google.com (mail-il1-x131.google.com [IPv6:2607:f8b0:4864:20::131]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FEB63A0FF9 for ; Fri, 4 Dec 2020 15:00:31 -0800 (PST) Received: by mail-il1-x131.google.com with SMTP id v3so6701962ilo.5 for ; Fri, 04 Dec 2020 15:00:31 -0800 (PST) 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=hjfmX6TmEgzQXABrb0zSMquacEn2WkAKRM07HIBjaVY=; b=gPdbX8famTNuEfQxFpDH5VU0WvKpi9qWZCk5jUwZkDRa3BWCRyZuSSDIYXtjwebBlw Qq2+aBf0MHMJuKIezKX5yBtfY9wC//8NmcBdkPkn5yCAkjHdIAa2Kige+rNhQQlIDxqT jn6+IGvoct1hoVLmwbse9BMIbw9YgYdbjrtzw= 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=hjfmX6TmEgzQXABrb0zSMquacEn2WkAKRM07HIBjaVY=; b=ckfti5t6i7XjqMKhb0FhwVCeUHYOtM4bVUugMZzN0GWeZUIBDuuLt7mC33KzZ5bohv wiSgE5hwEP1MkTedJ365Bf3Ffiwgi1OiorkHqLDEAUGXyEIBRerSDD2JlYn3eToSMpgu 1n88cv5etfde6hRXLcuDKzE1mp3ttrV14YIsxS1BqQWOX+8VeYzA3eS3WnSePC+dwKtq +Yy8NllwCU5erARPiGaScRGQMXMnBMR75qWfFBLNVpF5fYXV1Rej8UPcgBgrKnm0Bksx Tkj3WaeTObMWXa2JMLWh71TT7VLwp0D/pJL/JQZqV7PR3oaIbxmWZGTD1dKTC52h29uY 7xVQ== X-Gm-Message-State: AOAM532t94LzvXZfBAtDQcukVykXQyDUA4CH7nDEHP5VQqKIC8JFyewc IdHAcOwvkvgD0hDf18aocSg6JWqmkXOrYKUVl0pGew== X-Google-Smtp-Source: ABdhPJxBRnFpezBOpGzz382DSjug/1yYrhwnjjQCq618C/uDGpPxjYfrW0YYpA7eJuTmNviOaCjadreOEXtJR8dTt3o= X-Received: by 2002:a92:d2cc:: with SMTP id w12mr9545593ilg.120.1607122830581; Fri, 04 Dec 2020 15:00:30 -0800 (PST) MIME-Version: 1.0 References: <134860ee-5fbf-2fb3-a5b3-4be68806ab22@mtcc.com> <7224575d-685f-5020-073e-c1880acecc88@mtcc.com> <7e459496-61f8-ddcd-713c-3b6be448090c@gmail.com> <2cecceac-1add-44ec-6e16-e157fee293fe@mtcc.com> <5a577765-4a0d-e1bf-5321-dfeff19d107e@gmail.com> <40d7e78e-7026-c65c-383c-df4e3c537de3@mtcc.com> In-Reply-To: <40d7e78e-7026-c65c-383c-df4e3c537de3@mtcc.com> From: "Kurt Andersen (b)" Date: Fri, 4 Dec 2020 15:00:18 -0800 Message-ID: To: Michael Thomas Cc: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="0000000000006d6f3e05b5ab7155" Archived-At: Subject: Re: [dmarc-ietf] is DMARC informational? X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 04 Dec 2020 23:00:34 -0000 --0000000000006d6f3e05b5ab7155 Content-Type: text/plain; charset="UTF-8" On Fri, Dec 4, 2020 at 2:51 PM Michael Thomas wrote: > > What changed in the bis version to change its intended status? > The entire point of this working group (and the bis version that is in progress) is to move DMARC into the fully-recognized "standards" track. Note that even the current email specs are not "standards" in IETF parlance (there's another WG addressing that). It's mostly organizational semantic slicing-and-dicing. --Kurt --0000000000006d6f3e05b5ab7155 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Fri, Dec 4, 2020 at 2:51 PM Michael Th= omas <mike@mtcc.com> wrote:
<= /div>

What changed in the bis version to change its intended status?

The entire point of this working group (and the bis= version that is in progress) is to move DMARC into the fully-recognized &q= uot;standards" track. Note that even the current email specs are not &= quot;standards" in IETF parlance (there's another WG addressing th= at). It's mostly organizational semantic slicing-and-dicing.
=
--Kurt=C2=A0
--0000000000006d6f3e05b5ab7155-- From nobody Fri Dec 4 15: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 5F2403A0FF8 for ; Fri, 4 Dec 2020 15:01:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.65 X-Spam-Level: X-Spam-Status: No, score=-1.65 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, 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=mtcc-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lZWBNZCXTqXM for ; Fri, 4 Dec 2020 15:01:34 -0800 (PST) Received: from mail-pj1-x1029.google.com (mail-pj1-x1029.google.com [IPv6:2607:f8b0:4864:20::1029]) (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 C70353A0FF9 for ; Fri, 4 Dec 2020 15:01:34 -0800 (PST) Received: by mail-pj1-x1029.google.com with SMTP id e5so4016109pjt.0 for ; Fri, 04 Dec 2020 15:01:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mtcc-com.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=gr2inke//CkLOi0eboie5KKPRRWe8jojMhrFK1Gke24=; b=sbYUv7KpUdFJNy/GaOH6FTj/oY/MlVWSSG0FwQsZQVObLj9K/5568yv7Gsn5r3Q67K 6whyEqgRDdfCQcvigZa51jenmraryq/b/gcpp938xXyCEzU0NI4m8kntJiUHV5RlM6tG DYT1D79r+ZqNxmfK7HMt3SyUpAkwTl+eqZdxJD3thRaZ4Nyn0Ij1CxNKHTpIaArr70Lx 3iqzbry056BMAA1LWiRoPYGVfBth9g/Z4RgqdA+kYqD9qd4b63Rh72wCRRd91BNDjLnk hubFmKEqTi8xU2QdAZVin2Zj6niuS0d5TvzQLg5Q/uuCn/z0TwWmbI1j38WzITMAXC7M +7PA== 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=gr2inke//CkLOi0eboie5KKPRRWe8jojMhrFK1Gke24=; b=ZalfRpAinzghJ88S0J+7izdkYLN6t4XKHnFnxhOcbqxEIIoGrGg5p8YCPBF6MqXVqC TDQLVVj5aoNRAykDhkqWDABsxs9W8s6+8XswOJQln/Z9gHvip7o292pBzo0NDc2PO+BB 9hrValnDF+TybEzy/QBFEUGDPo0vLb1a8glYXqrAkAVo41ZOaj7ox50IbcCxXUvWfL+P B4ssVAEb4e0637+kMymQmzwBlvaWFldlSUJnixySPM64+leQI/rRue2DGepUpUf03UT+ bpgFlqgj2QXeN+O9L9GSyqGG5ktB/IE1LSqDgbf6yna+Apb9fabu2EamrsecbTSR/zwn in+A== X-Gm-Message-State: AOAM532mCtW1IqrTLsTRQfAbNkpDI5q8bFQ264m1a4hjDlgPjcah15Ca q/v2c6QEcVNEjRi3Hj53jNW9LFf5nF/yMA== X-Google-Smtp-Source: ABdhPJwuMO5gIyVZYCJ0MUT5/3472GrqwV4LV3mfqD5zmPIgSZZCSxcUTnZBqTpvlo9Etxtz4xNYXA== X-Received: by 2002:a17:902:7e85:b029:da:726a:3a4f with SMTP id z5-20020a1709027e85b02900da726a3a4fmr5833391pla.65.1607122893880; Fri, 04 Dec 2020 15:01:33 -0800 (PST) Received: from mike-mac.lan (107-182-42-33.volcanocom.com. [107.182.42.33]) by smtp.gmail.com with ESMTPSA id 77sm5978639pfv.16.2020.12.04.15.01.32 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 04 Dec 2020 15:01:33 -0800 (PST) To: Dave Crocker , Brandon Long Cc: "dmarc@ietf.org" References: <134860ee-5fbf-2fb3-a5b3-4be68806ab22@mtcc.com> <7224575d-685f-5020-073e-c1880acecc88@mtcc.com> <7e459496-61f8-ddcd-713c-3b6be448090c@gmail.com> <2cecceac-1add-44ec-6e16-e157fee293fe@mtcc.com> <5a577765-4a0d-e1bf-5321-dfeff19d107e@gmail.com> <40d7e78e-7026-c65c-383c-df4e3c537de3@mtcc.com> <6fae9ca6-d8ea-1d62-4156-249191029cc3@gmail.com> From: Michael Thomas Message-ID: <80f9963e-20bf-cdfe-cf3b-cda7b2ed08ab@mtcc.com> Date: Fri, 4 Dec 2020 15:01:31 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 MIME-Version: 1.0 In-Reply-To: <6fae9ca6-d8ea-1d62-4156-249191029cc3@gmail.com> Content-Type: multipart/alternative; boundary="------------B8F889DF376A45F262747DE3" Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] is DMARC informational? X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 04 Dec 2020 23:01:36 -0000 This is a multi-part message in MIME format. --------------B8F889DF376A45F262747DE3 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 12/4/20 2:59 PM, Dave Crocker wrote: > On 12/4/2020 2:51 PM, Michael Thomas wrote: >>> https://datatracker.ietf.org/wg/dmarc/documents/ >>> >> What changed in the bis version to change its intended status? > > There is a 'History' button to click on that page, to answer that > question. > 2020-11-11 00 Todd Herr New version available: *draft-ietf-dmarc-dmarcbis-00.txt* 2020-11-11 00 (System) Forced post of submission 2020-11-11 00 Todd Herr Set submitter to ""Todd M. Herr" ", replaces to (none) and sent approval email to group chairs: dmarc-chairs@ietf.org 2020-11-11 00 Todd Herr Uploaded new revision is responsive to my question in what way? Mike --------------B8F889DF376A45F262747DE3 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit


On 12/4/20 2:59 PM, Dave Crocker wrote:
On 12/4/2020 2:51 PM, Michael Thomas wrote:
https://datatracker.ietf.org/wg/dmarc/documents/

What changed in the bis version to change its intended status?

There is a 'History' button to click on that page, to answer that question.

2020-11-11
 00 Todd Herr New version available: draft-ietf-dmarc-dmarcbis-00.txt
2020-11-11
 00 (System) Forced post of submission
2020-11-11
 00 Todd Herr Set submitter to ""Todd M. Herr" <todd.herr@valimail.com>", replaces to (none) and sent approval email to group chairs: dmarc-chairs@ietf.org
2020-11-11
 00 Todd Herr Uploaded new revision


is responsive to my question in what way?

Mike
--------------B8F889DF376A45F262747DE3-- From nobody Fri Dec 4 15:03: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 BEC7B3A0FF8 for ; Fri, 4 Dec 2020 15:03:34 -0800 (PST) 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 pDmfBOI0X__Q for ; Fri, 4 Dec 2020 15:03:33 -0800 (PST) Received: from mail-vs1-xe31.google.com (mail-vs1-xe31.google.com [IPv6:2607:f8b0:4864:20::e31]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DCDEE3A1003 for ; Fri, 4 Dec 2020 15:03:32 -0800 (PST) Received: by mail-vs1-xe31.google.com with SMTP id v8so4200937vso.2 for ; Fri, 04 Dec 2020 15:03:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=eqHObeTQJ3qi2loD5lwX/Rvg78dkQTGA+L845QNAbPM=; b=gg0jY+goudAN6Bu5S+GJ1dSppZTf4s/ae8GiYWr+M6PDlcs0dpb0CVbNhrPDvTNMUv cK8NICk/nqsFa6zH6sdxKg2P48/xQ8Z1+50klCkMFRKtcAiO+XLEElslgF7vv+drhASr fS4KUGQ1Ou+FlTVZ8ufYm978VIwzDBhuejWhZhmBDeAMnvpTiI4rRb6+wnfUP55de130 SCeWEN4C2/0OoYf8FEV3xD3LZCPIb2o8O3lhfbSiKBw7qA0kC4mdq/t2TOIcXDa+haVN mvHo/SqarzMC8wFkYgT19F4sACN+tZ73nj2/cWSRFVAH8kQUiWLkyxXONSbXUedJH1te v3gg== 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=eqHObeTQJ3qi2loD5lwX/Rvg78dkQTGA+L845QNAbPM=; b=oL5sQO4WRnK432n94lHxhSYdMS+CsbAtVqbU1IjzBmHjyEssamqROHzi2UNLjQPTDU Acut8yyhPFhaAA+laj44+UVpzs9ju+In6ESOpVf9zE4aLXPhkPuqQYFwyllUDsZyqcVC bfIqZlP31V/kijbQX2f+wrWw/eFWWRAA7Cfp9H7UnG+chnwu95BsKxsCc07vscBVwBAi ITvclCOHT7QgbdP1CXWtDxkHE/77LmFSyCSBz3XgW0VDSrTdC47OqfJoxaAFHscPFKRa Tn7ktojKAbxSrLpvw58WDzpF519PpOtTp7A2rKVT8FRDZnhE4zCEZ1l/7xxCAc9IFDx1 6U5A== X-Gm-Message-State: AOAM530k4pvvwDxcGNvUOh7C8/o0oVbHC3D0m54H/klBWPwF64aqNBG9 q0pt551xolFtsPZbmsuxfLn9JoQx5bzTtuMr5iK5gzSk3kYIQw== X-Google-Smtp-Source: ABdhPJykihznh8JsQ45A/Sa7rje3St4T04u8R4SKlwimqil9HEZD1mfBoJTVcDeWgiDrfjf7ihqPapOzxPLPk+Qd/7E= X-Received: by 2002:a67:7983:: with SMTP id u125mr5945990vsc.41.1607123011690; Fri, 04 Dec 2020 15:03:31 -0800 (PST) MIME-Version: 1.0 References: <134860ee-5fbf-2fb3-a5b3-4be68806ab22@mtcc.com> <7224575d-685f-5020-073e-c1880acecc88@mtcc.com> <7e459496-61f8-ddcd-713c-3b6be448090c@gmail.com> <2cecceac-1add-44ec-6e16-e157fee293fe@mtcc.com> <5a577765-4a0d-e1bf-5321-dfeff19d107e@gmail.com> <40d7e78e-7026-c65c-383c-df4e3c537de3@mtcc.com> <6fae9ca6-d8ea-1d62-4156-249191029cc3@gmail.com> <80f9963e-20bf-cdfe-cf3b-cda7b2ed08ab@mtcc.com> In-Reply-To: <80f9963e-20bf-cdfe-cf3b-cda7b2ed08ab@mtcc.com> From: Seth Blank Date: Fri, 4 Dec 2020 15:03:21 -0800 Message-ID: To: IETF DMARC WG Content-Type: multipart/alternative; boundary="00000000000038f5cd05b5ab7cd5" Archived-At: Subject: Re: [dmarc-ietf] is DMARC informational? X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 04 Dec 2020 23:03:35 -0000 --00000000000038f5cd05b5ab7cd5 Content-Type: text/plain; charset="UTF-8" https://datatracker.ietf.org/meeting/108/materials/slides-108-dmarc-chairs-slides-00 On Fri, Dec 4, 2020 at 3:01 PM Michael Thomas wrote: > > On 12/4/20 2:59 PM, Dave Crocker wrote: > > On 12/4/2020 2:51 PM, Michael Thomas wrote: > > https://datatracker.ietf.org/wg/dmarc/documents/ > > What changed in the bis version to change its intended status? > > There is a 'History' button to click on that page, to answer that question. > > 2020-11-11 > 00 Todd Herr New version available: *draft-ietf-dmarc-dmarcbis-00.txt* > > 2020-11-11 > 00 (System) Forced post of submission > > 2020-11-11 > 00 Todd Herr Set submitter to ""Todd M. Herr" > ", replaces to (none) and sent approval email to > group chairs: dmarc-chairs@ietf.org > > 2020-11-11 > 00 Todd Herr Uploaded new revision > > > is responsive to my question in what way? > Mike > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > -- *Seth Blank* | VP, Standards and New Technologies *e:* seth@valimail.com *p:* 415.273.8818 This email and all data transmitted with it contains confidential and/or proprietary information intended solely for the use of individual(s) authorized to receive it. If you are not an intended and authorized recipient you are hereby notified of any use, disclosure, copying or distribution of the information included in this transmission is prohibited and may be unlawful. Please immediately notify the sender by replying to this email and then delete it from your system. --00000000000038f5cd05b5ab7cd5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Fri, Dec 4, 2020= at 3:01 PM Michael Thomas <mike@mtcc.c= om> wrote:
=20
On 12/4/2020 2:51 PM, Michael Thomas wrote:
https://= datatracker.ietf.org/wg/dmarc/documents/

What changed in the bis version to change its intended status?

There is a 'History' button to click on that page, to answ= er that question.

2020-11-11
 00 Todd Herr New version available: draft-ietf-dmarc-dmarcbis-00.txt
2020-11-11
 00 (System) Forced post of submission
2020-11-11
 00 Todd Herr Set submitter to ""Todd M. Herr" <= ;todd.herr@valimail.com>", replaces to (none) and sent approval email to group chairs: dmarc-chairs@ietf.org
2020-11-11
 00 Todd Herr Uploaded new revision


is responsive to my question in what way?

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


--

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


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

--00000000000038f5cd05b5ab7cd5-- From nobody Fri Dec 4 15:04: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 2D6CE3A10AD for ; Fri, 4 Dec 2020 15:04:32 -0800 (PST) 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 c2UmuMwgOtLC for ; Fri, 4 Dec 2020 15:04:31 -0800 (PST) Received: from mail-pg1-x52b.google.com (mail-pg1-x52b.google.com [IPv6:2607:f8b0:4864:20::52b]) (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 0E6C03A107D for ; Fri, 4 Dec 2020 15:04:30 -0800 (PST) Received: by mail-pg1-x52b.google.com with SMTP id g18so4468700pgk.1 for ; Fri, 04 Dec 2020 15:04:30 -0800 (PST) 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=t1/47gqpkyxWIcLyG/SEJ87RhVHQJTDO+tY5FjVkFZg=; b=VCSxTI/1j6f/BT8+ZrMzF2cNFvoOOprpJ8IX2NX0JnEdfdxKJO6eyS9ZWjCsfvd3fG lL6nCZrOmaKXyl9jLsiJRz9iYCkAJvQHNhpaY7AMsyugb4fFiJ++0hOA+fGKxttvsACl fdgeNFWvVerXoliBfD6zQBLIQw71UByqh9sxPJ1vFfmu06YWdHe9pTbXrTWloR8VVzwd 1Y32UrHPqI3eIT6z/Ncdt3N7J7TY+ew8gXmPfofl9P89W2I8SxshCUpkjeznnLpKRJDy WspG/ESZcNDtQSNNzSKDoUEoyq6M1zHBE1Zy2ubiGmGS4y6YbZ3kk46G8Xw4FiyZ8MiG ZczQ== 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=t1/47gqpkyxWIcLyG/SEJ87RhVHQJTDO+tY5FjVkFZg=; b=JvTYPvl8DCqIPxthLIgRN/SW59taClJMUlZ2VSihBdGNQDtb0R53Ru74xSn4PxT2mP ipBjjlkRZzPErIh6H2xzPphGNUs6wkaRU96VaQiL0jsUqhd39U6mShDeKgYNSPnE4Nv0 DZg17CfsKAAaF2b4PJEx7J/2jftuGxn3uMqAaLvUocI4ICNtRIIHlZYWCdzcPiUTnUNC Gb00A89ozo/9kTwrxALy+GEwvy4eO3Fub2LZHa5zGdydhqvkaLfTnrVgwqCwoyN9v2Nz cb7k9n0hnMBydV4k54LuKLucGg9riTKTO8WPSE4AvCRi51ouyFvJ4FeJcGk2rIeSHxbn c/gg== X-Gm-Message-State: AOAM531Jyz31uULFL4ujRMH/rxv64AAed5HOPorhzW76iBFOaZqpJfh6 Y6uzYwPc/xDPGtikPStAW56MP03yGM4= X-Google-Smtp-Source: ABdhPJwDBTXb/CAG4FDfWqniS8Rgx6J4+KBCN0WucMvSFQtwCcOgmoKic2BDutrFWRR3G4CvocR8lg== X-Received: by 2002:a65:42c7:: with SMTP id l7mr9367937pgp.438.1607123069422; Fri, 04 Dec 2020 15:04:29 -0800 (PST) Received: from [192.168.0.109] (c-24-130-62-181.hsd1.ca.comcast.net. [24.130.62.181]) by smtp.gmail.com with ESMTPSA id p15sm2835511pgi.40.2020.12.04.15.04.28 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 04 Dec 2020 15:04:28 -0800 (PST) To: Michael Thomas , Brandon Long Cc: "dmarc@ietf.org" References: <134860ee-5fbf-2fb3-a5b3-4be68806ab22@mtcc.com> <7224575d-685f-5020-073e-c1880acecc88@mtcc.com> <7e459496-61f8-ddcd-713c-3b6be448090c@gmail.com> <2cecceac-1add-44ec-6e16-e157fee293fe@mtcc.com> <5a577765-4a0d-e1bf-5321-dfeff19d107e@gmail.com> <40d7e78e-7026-c65c-383c-df4e3c537de3@mtcc.com> <6fae9ca6-d8ea-1d62-4156-249191029cc3@gmail.com> <80f9963e-20bf-cdfe-cf3b-cda7b2ed08ab@mtcc.com> From: Dave Crocker Message-ID: Date: Fri, 4 Dec 2020 15:04:27 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.5.1 MIME-Version: 1.0 In-Reply-To: <80f9963e-20bf-cdfe-cf3b-cda7b2ed08ab@mtcc.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] is DMARC informational? X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 04 Dec 2020 23:04:39 -0000 On 12/4/2020 3:01 PM, Michael Thomas wrote: > is responsive to my question in what way? You think "the working group created a new document" is not responsive? d/ -- Dave Crocker dcrocker@gmail.com 408.329.0791 Volunteer, Silicon Valley Chapter American Red Cross dave.crocker2@redcross.org From nobody Fri Dec 4 15:06: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 2D4393A1010 for ; Fri, 4 Dec 2020 15:06:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.652 X-Spam-Level: X-Spam-Status: No, score=-1.652 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mtcc-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fGN8USoFE9DV for ; Fri, 4 Dec 2020 15:06:09 -0800 (PST) Received: from mail-pg1-x52b.google.com (mail-pg1-x52b.google.com [IPv6:2607:f8b0:4864:20::52b]) (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 5D31E3A100F for ; Fri, 4 Dec 2020 15:06:09 -0800 (PST) Received: by mail-pg1-x52b.google.com with SMTP id t3so4434913pgi.11 for ; Fri, 04 Dec 2020 15:06:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mtcc-com.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=p0wBXm3bRNGmc7oeC54MW77Cpve38I8Z3IZlc0YQU9Y=; b=hXDZjzboONjRv8RyXJnwKtutjFSXaNNMOaFiiZYnpnpoaKBzacTLk3yGjlEdaAOgFm PW/0XYB5j/lwpINefaxBUBrSi0qmyeWKCBoEWVKmeKi26pIhpbrGjaKFv2RLlRESK8t8 emopfQNfP9RBMEVlD4Tbxi3+woSLZDzDELmEmN/0DeuFGkVk56e6p/dm8lmOv5/9zQ4i OsWs/EX70rS/Ruc/YSgBTTVt7rIqSDCf8rzUbP1N9Ijl8sx3c6f3ON+faN8UqqIIfld7 m282zSPkwJKD/oNU0yAIe8jixud3Axb+71mFFHaOxAIWLNF+vgto+6DYlcCRnBR08oQo Txnw== 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=p0wBXm3bRNGmc7oeC54MW77Cpve38I8Z3IZlc0YQU9Y=; b=io/0Nyt+pUODVfIJ+bPrQ3jEUVkUkQe27pMhnqD0opDe316vIvTb4MPl6vZba0Ch/b 2zijL4TXkMgr9Rn86a9iwxzvw3vLT+Yu5GdwT+Dz9iDZ9Gwfy8D2F+IgEuaZ0jridnw4 tP2q2FFXw77r9vnbWfr3EQh3KLUemZofemzhfVCSul+RZAAtGxlaStdVAVkHwtENBYDQ huLucjySkShF9aAvJCTC75wPhmmZF44JV6s9LgTlUTXmrTxDsDPYDZSHNFqeacEAdyT5 9zZ67nSJfIEpp38XwJMYD2YgkAsoYmamjGZCkSM6Fd3nxo+IF3jcrf1r/AzmO8PBTTnf SSNw== X-Gm-Message-State: AOAM531pR9vKY6M832gPFCvikQnSowTTBLepMUDmNuvbGNaJxV0tsekO ACwOFnUVOkvczS7xwwTAyXKwspp/FSUR6w== X-Google-Smtp-Source: ABdhPJzAeaAMtKeJynd2c9BDqnKuTb/3zHf9QggugwU+aO3WWvlo+Q4hszUgJTbfaMuUpX5+fGDh7Q== X-Received: by 2002:a65:684f:: with SMTP id q15mr9180678pgt.125.1607123168512; Fri, 04 Dec 2020 15:06:08 -0800 (PST) Received: from mike-mac.lan (107-182-42-33.volcanocom.com. [107.182.42.33]) by smtp.gmail.com with ESMTPSA id u1sm5481584pfn.181.2020.12.04.15.06.07 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 04 Dec 2020 15:06:07 -0800 (PST) To: Dave Crocker , Brandon Long Cc: "dmarc@ietf.org" References: <134860ee-5fbf-2fb3-a5b3-4be68806ab22@mtcc.com> <7224575d-685f-5020-073e-c1880acecc88@mtcc.com> <7e459496-61f8-ddcd-713c-3b6be448090c@gmail.com> <2cecceac-1add-44ec-6e16-e157fee293fe@mtcc.com> <5a577765-4a0d-e1bf-5321-dfeff19d107e@gmail.com> <40d7e78e-7026-c65c-383c-df4e3c537de3@mtcc.com> <6fae9ca6-d8ea-1d62-4156-249191029cc3@gmail.com> <80f9963e-20bf-cdfe-cf3b-cda7b2ed08ab@mtcc.com> From: Michael Thomas Message-ID: <1563226c-6434-9b8a-5a3d-bb7fe8590221@mtcc.com> Date: Fri, 4 Dec 2020 15:06:06 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.5.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] is DMARC informational? X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 04 Dec 2020 23:06:11 -0000 On 12/4/20 3:04 PM, Dave Crocker wrote: > On 12/4/2020 3:01 PM, Michael Thomas wrote: >> is responsive to my question in what way? > > You think "the working group created a new document" is not responsive? > No. Mike From nobody Fri Dec 4 15:06: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 472C63A103C for ; Fri, 4 Dec 2020 15:06:15 -0800 (PST) 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 AqRUIk0nFBtk for ; Fri, 4 Dec 2020 15:06:13 -0800 (PST) Received: from mail-pf1-x434.google.com (mail-pf1-x434.google.com [IPv6:2607:f8b0:4864:20::434]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 98F9A3A1012 for ; Fri, 4 Dec 2020 15:06:13 -0800 (PST) Received: by mail-pf1-x434.google.com with SMTP id f9so4198889pfc.11 for ; Fri, 04 Dec 2020 15:06:13 -0800 (PST) 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=SmkWBM5barcizC4SbwWvqYpwvGCc4Od9m3896CLdBL4=; b=WxL6m4JEAg9Ocwv4JzEPWiA/SfvTlnNA1kDPAy1Sq9fWXcl3D4+iFAxywtJJIuoFKD 1N/vt+6O5dxyFciSqvpmOrGVA9F2Voee2uQhNelcl9VyOo0DGR8WJFUV6PqTJPBiFDQB enrcPssEtnWQQj3vH4W670JCw51suMHM7WibXJKE1hgq/VDb8rmCbq9gdZ/FS6DO7z33 NKbu+yUYinyrhnfHS9mstpHd3vznaklflAElUdnk9Ypux7X/Ihti87pSjaLIy2kNTIFf tKBA34L1hBLv3lEnbBgKfa2WOOEfpzgZNxPb7ndsQVlT2aXsK5gwlVTJKiQ54VKzUSW3 bSsg== 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=SmkWBM5barcizC4SbwWvqYpwvGCc4Od9m3896CLdBL4=; b=tS7CIkv//2AymEwA0qHE9Amiz2uPbx3YSMl/mkTO9IhKViCUlgofWPBpvro69TWrph hmbqt9/gs9kIy8LeJcrccQ7HFA8ZqGCyzxQpghRr0V+HJkgTWWuE4fQl0j4lEInPx4cO 3gB0WCc52wn7i+7kwwWC5k/PiMjCZTRp6T7sNRb+OrWmhp5W31E908so5Zknro93KHpa AeouVL/Wp8EBVZvTl75mL9fvKMinsSfcNEMyEl5os2IeascZrG9oVBKeCJHm9XAshbQ3 fFkLEOwf5r0sDcLejtBTK8Nx2Mpf+gdd6uE8qg5mC40B+8DVHIVwC4RRucrDpDG0GaR+ UQVA== X-Gm-Message-State: AOAM532dt0qry62hjY4Ku0Lvbruho2tixczyV8mJob6w2l4DwcyfIfKh I4pGtiN3d1OWggwQx3ykLrJXo9f33Sc= X-Google-Smtp-Source: ABdhPJw6e4HLNLfc7vAS55mouVswGj+ldkhxT0qHNnGR6wW+cdX+TWcK9/V+fcOd/kw8CQztkIfLcQ== X-Received: by 2002:aa7:8552:0:b029:18e:f030:e514 with SMTP id y18-20020aa785520000b029018ef030e514mr6108114pfn.2.1607123172957; Fri, 04 Dec 2020 15:06:12 -0800 (PST) Received: from [192.168.0.109] (c-24-130-62-181.hsd1.ca.comcast.net. [24.130.62.181]) by smtp.gmail.com with ESMTPSA id z25sm4759873pge.66.2020.12.04.15.06.12 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 04 Dec 2020 15:06:12 -0800 (PST) To: Seth Blank , IETF DMARC WG References: <134860ee-5fbf-2fb3-a5b3-4be68806ab22@mtcc.com> <7224575d-685f-5020-073e-c1880acecc88@mtcc.com> <7e459496-61f8-ddcd-713c-3b6be448090c@gmail.com> <2cecceac-1add-44ec-6e16-e157fee293fe@mtcc.com> <5a577765-4a0d-e1bf-5321-dfeff19d107e@gmail.com> <40d7e78e-7026-c65c-383c-df4e3c537de3@mtcc.com> <6fae9ca6-d8ea-1d62-4156-249191029cc3@gmail.com> <80f9963e-20bf-cdfe-cf3b-cda7b2ed08ab@mtcc.com> From: Dave Crocker Message-ID: <53fefbe7-ed4e-e878-daa3-3f027772cad3@gmail.com> Date: Fri, 4 Dec 2020 15:06:11 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.5.1 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] is DMARC informational? X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 04 Dec 2020 23:06:22 -0000 On 12/4/2020 3:03 PM, Seth Blank wrote: > https://datatracker.ietf.org/meeting/108/materials/slides-108-dmarc-chairs-slides-00 > Surprisingly, the wg datatracker page also has a 'Meetings' button. d/ -- Dave Crocker dcrocker@gmail.com 408.329.0791 Volunteer, Silicon Valley Chapter American Red Cross dave.crocker2@redcross.org From nobody Fri Dec 4 15:07: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 0BC783A100F for ; Fri, 4 Dec 2020 15:07:03 -0800 (PST) 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 PuhoxRhE7iOP for ; Fri, 4 Dec 2020 15:07:01 -0800 (PST) Received: from mail-pl1-x636.google.com (mail-pl1-x636.google.com [IPv6:2607:f8b0:4864:20::636]) (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 645F93A1011 for ; Fri, 4 Dec 2020 15:07:01 -0800 (PST) Received: by mail-pl1-x636.google.com with SMTP id bj5so3981829plb.4 for ; Fri, 04 Dec 2020 15:07:01 -0800 (PST) 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=I2p5TuINvw98jkRRWOfNGFrmODguKjn/2iZtMq3srQA=; b=h68eFoEo52tUQwM6e+mhVYaf/yFcGs4jM5GsTU9vBgfbfpz+6waqkAC7t2oWjISOuw Rbagp8esMnUuwYA6ncA79Qe7X55FKH6s1N9fOSyw8GjwhUJqsN3fC1HyRF6Od0fZXp4H KJXTh/+q9rVCtCGA1zKm53XuWpnsGRMyhsIwAWJnKFcWus1N6tOTeJotwAvDbNYElTri +cedQdwojFBT/CjwF4cfyWwLJdblfs0csbvr/mFqntqdYArBh9wN9K58Au4HkZsVSkG/ ZzlDLjPAiRerScbaQ6XDf4EIQTrqITJ3tL6gT/1Jv2K8PbuC+ubDYZzjCV+OCMzKfeQI fTdw== 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=I2p5TuINvw98jkRRWOfNGFrmODguKjn/2iZtMq3srQA=; b=phhgTlJV+NcAhS+jhj5BX/Oz4/wHLGzSCD5fMRV6S1Ax6eQkMMGqPaiJSDbVVe3SIQ USGthpWdd5h7rpCDGdG4LhzuiY4zGDmqZP/vOyyLiEUXI18xLK8isZeISzYaHDu2lnoT pLF1Et1YdwwJXkYL8Rd66qQL8h2bysxFjj8lDgtgiVtf/SztacRW4NPqGm1E4tkC8lYp mGiFRNd0o905+9RDj1DB9AcmfjV9KgSRD8dSWUj8pwwA4Xt+44SLpSHZKyOzV8dsJkkZ LRU1SVKsfjCJUXva3FZh3Mwx41IYXYr4QdyLzZ+xmcBQusgRNZuptUDHRYhH65akQuI0 zemg== X-Gm-Message-State: AOAM532tscvyJLgYySSFRneA1jtiSnCJxfvPxmkjUJ+cXHwI3CfavRga 4Nyzj+81oWFp/vAKbggoPpAIW6jh3L8= X-Google-Smtp-Source: ABdhPJzslfuznn0/s9bRTFrnFYR7jDZaAOtnPLKDlT17piH7ioNR65Z4fQaxGo33ECyS2CAHVqtvrg== X-Received: by 2002:a17:902:be02:b029:da:c6c9:c9db with SMTP id r2-20020a170902be02b02900dac6c9c9dbmr5731151pls.69.1607123220706; Fri, 04 Dec 2020 15:07:00 -0800 (PST) Received: from [192.168.0.109] (c-24-130-62-181.hsd1.ca.comcast.net. [24.130.62.181]) by smtp.gmail.com with ESMTPSA id t22sm5491604pja.1.2020.12.04.15.06.59 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 04 Dec 2020 15:07:00 -0800 (PST) To: Michael Thomas , Brandon Long Cc: "dmarc@ietf.org" References: <134860ee-5fbf-2fb3-a5b3-4be68806ab22@mtcc.com> <7224575d-685f-5020-073e-c1880acecc88@mtcc.com> <7e459496-61f8-ddcd-713c-3b6be448090c@gmail.com> <2cecceac-1add-44ec-6e16-e157fee293fe@mtcc.com> <5a577765-4a0d-e1bf-5321-dfeff19d107e@gmail.com> <40d7e78e-7026-c65c-383c-df4e3c537de3@mtcc.com> <6fae9ca6-d8ea-1d62-4156-249191029cc3@gmail.com> <80f9963e-20bf-cdfe-cf3b-cda7b2ed08ab@mtcc.com> <1563226c-6434-9b8a-5a3d-bb7fe8590221@mtcc.com> From: Dave Crocker Message-ID: <12f97066-010f-4027-1191-a7c569688419@gmail.com> Date: Fri, 4 Dec 2020 15:06:58 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.5.1 MIME-Version: 1.0 In-Reply-To: <1563226c-6434-9b8a-5a3d-bb7fe8590221@mtcc.com> Content-Type: multipart/alternative; boundary="------------EBC614045585E6EA94CCA7FD" Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] is DMARC informational? X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 04 Dec 2020 23:07:03 -0000 This is a multi-part message in MIME format. --------------EBC614045585E6EA94CCA7FD Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 12/4/2020 3:06 PM, Michael Thomas wrote: >> You think "the working group created a new document" is not responsive? >> > No. odd.  why not? d/ -- Dave Crocker dcrocker@gmail.com 408.329.0791 Volunteer, Silicon Valley Chapter American Red Cross dave.crocker2@redcross.org --------------EBC614045585E6EA94CCA7FD Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 12/4/2020 3:06 PM, Michael Thomas wrote:
You think "the working group created a new document" is not responsive?

No.

odd.  why not?

d/

-- 
Dave Crocker
dcrocker@gmail.com
408.329.0791

Volunteer, Silicon Valley Chapter
American Red Cross
dave.crocker2@redcross.org
--------------EBC614045585E6EA94CCA7FD-- From nobody Fri Dec 4 15:11: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 425D23A0D43 for ; Fri, 4 Dec 2020 15:11:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.65 X-Spam-Level: X-Spam-Status: No, score=-1.65 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, 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=mtcc-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pkJ1AFAsyhRH for ; Fri, 4 Dec 2020 15:11:19 -0800 (PST) Received: from mail-pg1-x52f.google.com (mail-pg1-x52f.google.com [IPv6:2607:f8b0:4864:20::52f]) (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 8B3853A09D7 for ; Fri, 4 Dec 2020 15:11:19 -0800 (PST) Received: by mail-pg1-x52f.google.com with SMTP id q3so4473168pgr.3 for ; Fri, 04 Dec 2020 15:11:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mtcc-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=mPjOKUyJNlDb7n/kiwgqTJSb0M5G0Whc5vxuMShgtTM=; b=otdtyYkY47kdrt5FjqYekyXb748U9mBpBWAK63KgeOZL/s0b1bo4Zl5ngAFKPOno4o rS33n42rAPagqgdX6lOTSfZICtsZSpHV/trmRQyDIX5UYihG5QIFTngYxRK3WLsT8eGD OXQj8STIaDrM4WqBoQ3RoJEyJ2N/UNugTo0fAYTV0cvZBax6SBDdUWSA3Ia5gz3CAIke 20qrONDiytYySZWHB894Pjqkxe+38zEV8XcT29eOvGrqcTwf+rD04yUptHWUxvqP/tNb HFkz/suGRc6sZR0TZiBAl8zueyoKkjvSkP2uuLURqlXN4mJ0C4ovFdkWrW/IdvljaDnu Xoaw== 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=mPjOKUyJNlDb7n/kiwgqTJSb0M5G0Whc5vxuMShgtTM=; b=gEvZ2+fMATMCXDCfQsIIrpARvlP8/hGYjxcnrm7xXk7JmvK5VeXPthEcyh0uIt07tm ab56eSkf5ABx1PJzzSSJ0ySdhGPZ4tqKBM7ho1Cw1G9Lt5d9Z18qPkCBNfaF8BtaktMD VdmioJfjDKBbJIbjeExHm9QSW5YSNHYcob7RoVrqHvltJouG9K4U08km6Mxf8E5aJ2bi fl3deD1toyoWvYet/6zDkFmq5i6RiB+S9BywZy0ZE8JDnavLfTl6UdcQ0CGhdEUrT2p3 1XT06XPclOtOkaIdtWTv7vSHkO5SGzCsXNfReUjwrbYLBSLbF1OUfRDlv/mKeYdVW8FN +LfQ== X-Gm-Message-State: AOAM532Jyimvt9sSShUy6RrmJQ6GCFIldgQ36uIJJHLRkZpqvsqsl3RD S/Iiwv2zC2oNyH1CtLFmJeLjEwCMot4tPQ== X-Google-Smtp-Source: ABdhPJwY8J/gWOsVdNFJaErXRIhOGi9IUS3Pi8WMPkQVgUkolOa8s+M8Ext0CSsn/tcU8uhgsJAivA== X-Received: by 2002:a05:6a00:1683:b029:19d:917a:616b with SMTP id k3-20020a056a001683b029019d917a616bmr5938514pfc.15.1607123478518; Fri, 04 Dec 2020 15:11:18 -0800 (PST) Received: from mike-mac.lan (107-182-42-33.volcanocom.com. [107.182.42.33]) by smtp.gmail.com with ESMTPSA id k189sm6713376pfd.99.2020.12.04.15.11.17 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 04 Dec 2020 15:11:17 -0800 (PST) To: dmarc@ietf.org References: <134860ee-5fbf-2fb3-a5b3-4be68806ab22@mtcc.com> <7224575d-685f-5020-073e-c1880acecc88@mtcc.com> <7e459496-61f8-ddcd-713c-3b6be448090c@gmail.com> <2cecceac-1add-44ec-6e16-e157fee293fe@mtcc.com> <5a577765-4a0d-e1bf-5321-dfeff19d107e@gmail.com> <40d7e78e-7026-c65c-383c-df4e3c537de3@mtcc.com> <6fae9ca6-d8ea-1d62-4156-249191029cc3@gmail.com> <80f9963e-20bf-cdfe-cf3b-cda7b2ed08ab@mtcc.com> From: Michael Thomas Message-ID: Date: Fri, 4 Dec 2020 15:11:16 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------2ED3720F309A0E7317309B54" Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] is DMARC informational? X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 04 Dec 2020 23:11:21 -0000 This is a multi-part message in MIME format. --------------2ED3720F309A0E7317309B54 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Is it really that hard to summarize why the decision was made and what changed in the bis version? I really don't understand this snipe hunt. Mike On 12/4/20 3:03 PM, Seth Blank wrote: > https://datatracker.ietf.org/meeting/108/materials/slides-108-dmarc-chairs-slides-00 > > > On Fri, Dec 4, 2020 at 3:01 PM Michael Thomas > wrote: > > > On 12/4/20 2:59 PM, Dave Crocker wrote: >> On 12/4/2020 2:51 PM, Michael Thomas wrote: >>>> https://datatracker.ietf.org/wg/dmarc/documents/ >>>> >>>> >>> What changed in the bis version to change its intended status? >> >> There is a 'History' button to click on that page, to answer that >> question. >> > 2020-11-11 > 00 Todd Herr New version available: > *draft-ietf-dmarc-dmarcbis-00.txt* > 2020-11-11 > 00 (System) Forced post of submission > 2020-11-11 > 00 Todd Herr Set submitter to ""Todd M. Herr" > ", > replaces to (none) and sent approval email to group chairs: > dmarc-chairs@ietf.org > 2020-11-11 > 00 Todd Herr Uploaded new revision > > > is responsive to my question in what way? > > Mike > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > > > > > -- > *Seth Blank*| VP, Standards and New Technologies > *e:*seth@valimail.com > *p:*415.273.8818 > > > This email and all data transmitted with it contains confidential > and/or proprietary information intended solely for the use of > individual(s) authorized to receive it. If you are not an intended and > authorized recipient you are hereby notified of any use, disclosure, > copying or distribution of the information included in this > transmission is prohibited and may be unlawful. Please immediately > notify the sender by replying to this email and then delete it from > your system. > > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc --------------2ED3720F309A0E7317309B54 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit

Is it really that hard to summarize why the decision was made and what changed in the bis version? I really don't understand this snipe hunt.

Mike

On 12/4/20 3:03 PM, Seth Blank wrote:

On Fri, Dec 4, 2020 at 3:01 PM Michael Thomas <mike@mtcc.com> wrote:


On 12/4/20 2:59 PM, Dave Crocker wrote:
On 12/4/2020 2:51 PM, Michael Thomas wrote:
https://datatracker.ietf.org/wg/dmarc/documents/

What changed in the bis version to change its intended status?

There is a 'History' button to click on that page, to answer that question.

2020-11-11
 00 Todd Herr New version available: draft-ietf-dmarc-dmarcbis-00.txt
2020-11-11
 00 (System) Forced post of submission
2020-11-11
 00 Todd Herr Set submitter to ""Todd M. Herr" <todd.herr@valimail.com>", replaces to (none) and sent approval email to group chairs: dmarc-chairs@ietf.org
2020-11-11
 00 Todd Herr Uploaded new revision


is responsive to my question in what way?

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


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


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


_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
--------------2ED3720F309A0E7317309B54-- From nobody Fri Dec 4 15:19: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 2DA353A102A for ; Fri, 4 Dec 2020 15:19:41 -0800 (PST) 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 5qYqKxJvTt7H for ; Fri, 4 Dec 2020 15:19:38 -0800 (PST) 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 523A43A0DD2 for ; Fri, 4 Dec 2020 15:19:38 -0800 (PST) Received: by mail-vs1-xe2c.google.com with SMTP id v8so4218900vso.2 for ; Fri, 04 Dec 2020 15:19:38 -0800 (PST) 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=0xs7Fcxp6oEut6e0LMGEt0XikgyLXESGb/dcQgZd6u4=; b=tpJkd6dH9+efgfN1o0mO+v9mMIg4SlWwtNCoYg+WGhFPQnezoZ9EvjDbPsrFIz1C66 7RnF7LTBMbu5CAeWlRlobwhu5DjsqstANMNdV07xbiJdXFkrU7Bg4hAci6CdZ6Z/Uhie kppleovvJuTX1Z4LJ5Hyxjo72UA584VmCZyR7qrEQ2q61wDAIv130SMG0Jf6G/iwvnOB WpUGOmmSxVjD4+Cb9h1/VCQ0WmbckUSIUaz2oi9k9SdwkzF5NmHIkO1XzLRLpltQiuxX dSBMBH56wOgUXXf6CVRBgKEKVXKeNa2BzSxZ7rSh6mL52srqpyt7wTisr8+YwLAsRETh vNyw== 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=0xs7Fcxp6oEut6e0LMGEt0XikgyLXESGb/dcQgZd6u4=; b=T4q2uIc7IB5KEMr0f0QM9fsZgF64dv03CbG24OikprqU6+uTlXuaGdKVwf+EcJW5fw wiP2Wi2O6vk3p4nwHZmKwEaJ7hEYdGSjcfMEauI3wyh7/0jzcQ/MELEUW1ZI6GGixHrD dHKsq4XDJqis4hDNB4Rbjpz4vPLvP1YLiB1sGc89zLanT4jIA13K/POKBmcIxCNuVf6f htj97hUroHAocmcSmDcUVZWXwlZf5bCiJ7z/QSvPwxuHkSG6AqWkYR/G60FjM16oj5BX Afy5fZWc5rNaPpLIyOiJQSqEehSiHYvNhxnvvsUiIyZCQeI2DltYeUDgJruZ0p0VacB5 F53w== X-Gm-Message-State: AOAM530HgTkAN3kuQ+cGaxH1AraIC8lzGW4mSpeKyj6ucoylNg6c/ptw zETHSveU3fhnHsjK5qiczkzaHpEW+UfWTMWSDag4 X-Google-Smtp-Source: ABdhPJxDzwPj1YTkGOiu7qn3fdzc0bkHp6hT22kz3C4Ah3wPvtEl/5pAGtBTG3dMNGEJvoW4zo8O3OhKXQ9BHjS+1Fk= X-Received: by 2002:a05:6102:215c:: with SMTP id h28mr5949465vsg.58.1607123976970; Fri, 04 Dec 2020 15:19:36 -0800 (PST) MIME-Version: 1.0 References: <20201124020453.AFDC027CE5C8@ary.qy> <1eed8278-4efa-4abc-15e0-2efcf014e82e@mtcc.com> <446d491b-100a-9813-6463-2294f67bbda7@mtcc.com> In-Reply-To: <446d491b-100a-9813-6463-2294f67bbda7@mtcc.com> From: Brandon Long Date: Fri, 4 Dec 2020 15:19:24 -0800 Message-ID: To: Michael Thomas Cc: John Levine , IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000c27b4c05b5abb59d" Archived-At: Subject: Re: [dmarc-ietf] ARC questions X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 04 Dec 2020 23:19:41 -0000 --000000000000c27b4c05b5abb59d Content-Type: text/plain; charset="UTF-8" On Wed, Dec 2, 2020 at 12:13 PM Michael Thomas wrote: > > On 11/30/20 9:43 PM, Brandon Long wrote: > > > To summarize what I said already in this thread, DKIM is taken by many > receivers as the responsible party for a message, in both spam and phishing > classifiers, with the latter being perhaps more relevant. > DMARC is the one example of that. DKIM signing a message that transits > your system allows for reputation washing of the original message. The ARC > chain is specified as a relay responsibility, which is a lesser burden. > > Ignoring the existing usage of DKIM, DKIM+A-R would only work for a single > hop, and lead to some complication compared to the other DKIM signatures > already on the message. > > Wait, what? a DKIM signatures survives until it encounters an intermediary > that alters the message in a breaking manner. Arc-Signatures are no > different in that respect. In fact as far as I can tell they are identical > modulo the i= difference. > I'm unsure about the disconnect we are having in our conversation, but I shall try again. Yes, a DKIM signature and an AMS both break if the message is altered in the wrong way. If you use a DKIM signature to sign the A-R header, you're choosing to sign against a header which is often removed by existing infrastructure due to that removal being part of the RFC for that header, which will invalidate the signature. Yes, the remover can validate the signature before removing it, but anyone downstream is now lost... so now the remover would have to remove the signature and re-sign. And fundamentally, every time the message has a breaking alteration, the message would need to be re-signed. And every time you add another A-R for another domain, you'd have to sign, just like we do in ARC. Except you can only sign with your own key, so now the message you've modified in some manner has acquired your signature. What does that mean to the existing systems? Well, at Google that means if we receive the message, we will perform spam classification on it based on the reputation of the DKIM signature domain, and update the reputation of the domain based no the results. This isn't uncommon. If we perform DMARC verification, we do so against the DKIM signatures on the message. The DKIM signature makes you "responsible" for the message. Adding an A-R header doesn't seem like the kind of thing that should justify extra responsibility. When we argue that changing the From header of messages on mailing lists because they have now become the "author" of the message by modifying it, folks rightly object. The modifications that are made are automated and clear, the actual "intended" authorship of the message is mostly unchanged, why should the mailing list take responsibility? ARC makes that differentiation, the AMS is saying "I take responsibility for what should be a minor change" and for the A-R results. You can use this to say "ok" or not. You could potentially evaluate that over time, even, by seeing the messages that are sent directly and indirectly. How you do that is an unknown, hence the experimental nature of this RFC. > DKIM is not the only thing that can be reputation washed, SPF can as > well. 821.FROM rewriting is more common, so there are work-arounds. OTOH, > SPF doesn't survive forwarding, but with ARC you can forward it. DKIM+A-R > would only work for a single hop, and lead to some complication compared to > the other DKIM signatures already on the message. > > > > >> So mtcc.com is now hosted by gsuite (::sigh::), so you're saying that it >> would run into problems? I haven't put up a DMARC policy, but if I did I >> might run into issues with false positives? Like I said, I'm trying to get >> my head around what the actual problems are, and this is coming from a >> person who stressed mightily from the very beginning about the mailing list >> problem. >> > It's unlikely you have a complicated mail flow involving multiple vendors, > but certainly there are plenty of configuration options alllowing folks to > shoot themselves in the foot. > > By definition a message hitting the front door of the destination domain > (via an MX record) sees the DKIM signatures in the message and can process > them at that point, or at some point before other manglers get a hold of > the message. I don't see why we should care at all about what happens > beyond the destination domain's front door because that's their problem not > ours. The entire point of DKIM is the inter-domain case, not intra-domain. > My point is that for large organizations, the difference between inter-domain and intra-domain becomes much weaker. And I think we're interested in the entire mail ecosystem, which would include passing such information between intra-domain email vendors. > With ARC, we can instead say "trust this arc admd" and have the data > passed directly, and also work around the DKIM breakage. > > But ARC suffers the same breakage with the ARC-Signature. And if the > ARC-Signature is broken, you can't trust the sealed data because that's a > trivial cut and paste attack as far as I can see. So I'm just not seeing > how this is any better than just a plain old DKIM-Signature with the old > auth-res renamed and signed since you can already for 15 years trust > signing intermediaries or not. > ARC requires the last AMS to be valid for the chain to be intact, yes. It does not require that all AMS be valid. That does mean that content wise, only the last AMS has a strong ownership of the message. ARC in this case does not have the same strength as DKIM. > As for another comment in the thread about adding two signatures per hop, > there was a suggestion that it could be replaced with a single signature > per hop near last call with some loss of information (maybe), but it was > decided to move forward with the existing solution that already had several > implementations and was experimental anyways. > > As I said elsewhere, since this is an active experiment and it's already > been a year, it might be good to start documenting what the experiment is > teaching us. I still after many messages have no clue what what ARC does > that DKIM+old-auth-res cannot beyond tying the authres and signature > together. It would be nice to know in a quantitative way why that is > important, as well as any other things that cannot be done with > DKIM+old-auth-res. > I've cited a number of definitional reasons why your scheme would not work, I'm unclear what quantitative information would change that fact. ARC was designed to actually handle the use case you're talking about without breaking in obvious ways. What the ARC experiment is actually asking is whether the added information is useful. That information has been provided at various points, and certainly we should do so again, but adoption has been slow. That may mean the experiment will fail. At Google with limited adoption externally and without us even doing all of the things with it that we originally wanted, it has been useful in a number of corner cases and flows. That is not sufficient for the ecosystem at large, of course, we need adoption and better usage to see at scale. The utility is always going to be somewhat at the margins, however... 95% of messages we received were spf authenticated (and presumably nearly directly sent) back in 2013 ( https://security.googleblog.com/2013/12/internet-wide-efforts-to-fight-email.html), and I think the numbers of increased since then. > In fact since I expect that most signature breaking intermediaries DKIM > resign the messages (and if they don't thay aren't going to do ARC either), > it would be very simple to chronicle how the two approaches differ in > efficacy. The same reputation look for ARC can be done for DKIM too, after > all. > When the dmarc-apocalypse happened, relatively few mailing list hosters DKIM signed their messages... and I don't think any interdomain relays do for the reasons I keep citing. ARC and DKIM may be similarly technically, but they are meant to impart different information and be used in different ways, they are not the same. > BTW: i can understand not wanting to touch DKIM or AUTH-RES proper for an > experiment, but a standards track document should really consider just > adding the binding tag to DKIM and Auth-res. They were both designed to be > able to do that. > A-R was not designed to allow arbitrary tags, only ones for specific cases. DKIM was designed for new tags, but adding them won't automatically change how systems are interpreting them today. Brandon --000000000000c27b4c05b5abb59d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Dec 2, 2020 at 12:13 PM Micha= el Thomas <mike@mtcc.com> wrote:=
=20 =20 =20


On 11/30/20 9:43 PM, Brandon Long wrote:
=20

To summarize what I said already in this thread, DKIM is taken by many receivers as the responsible party for a message, in both spam and phishing classifiers, with the latter being perhaps more relevant.
DMARC is the one example of that.=C2=A0 DKIM signing a messa= ge that transits your system allows for reputation washing of the original message.=C2=A0 The ARC chain is specified as a rel= ay responsibility, which is a lesser burden.

Ignoring the existing usage of DKIM, DKIM+A-R would only work for a single hop, and lead to some complication compared to the other DKIM signatures already on the message.

Wait, what? a DKIM signatures survives until it encounters an intermediary that alters the message in a breaking manner. Arc-Signatures are no different in that respect. In fact as far as I can tell they are identical modulo the i=3D difference.

I'm unsure about the disconnect we are having in ou= r conversation, but I shall try again.

Yes, a DKIM= signature and an AMS both break if the message is altered in the wrong way= .=C2=A0 If you use a DKIM signature to sign the A-R header, you're choo= sing to sign against a header which is
often removed by existing = infrastructure due to that removal being part of the RFC for that header, w= hich will invalidate the signature.=C2=A0 Yes, the remover can validate the= signature before removing it, but anyone downstream is now lost... so now = the remover would have to remove the signature and re-sign.

<= /div>
And fundamentally, every time the message has a breaking alterati= on, the message would need to be re-signed.=C2=A0 And every time you add an= other A-R for another domain, you'd have to sign, just like we do in AR= C.

Except you can only sign with your own key, so now the mes= sage you've modified in some manner has acquired your signature.=C2=A0 = What does that mean to the existing systems?=C2=A0 Well, at Google that mea= ns if we receive the message, we will perform spam classification on it bas= ed on the reputation of the DKIM signature domain, and update the reputatio= n of the domain based no the results.=C2=A0 This isn't uncommon.=C2=A0 = If we perform DMARC verification, we do so against the DKIM signatures on t= he message.=C2=A0 The DKIM signature makes you "responsible" for = the message.

Adding an A-R header doesn't seem= like the kind of thing that should justify extra responsibility.=C2=A0 Whe= n we argue that changing the From header of messages on mailing lists becau= se they have
now become the "author" of the message by = modifying it, folks rightly object.=C2=A0 The modifications that are made a= re automated and clear, the actual "intended" authorship of the m= essage is mostly
unchanged, why should the mailing list take resp= onsibility?

ARC makes that differentiation, the AM= S is saying "I take responsibility for what should be a minor change&q= uot; and for the A-R results.=C2=A0 You can use this to say "ok" = or not.=C2=A0 You could potentially evaluate that over time, even, by seein= g the messages that are sent directly and indirectly.=C2=A0 How you do that= is an unknown, hence the experimental nature of this RFC.
=C2=A0=
=20
DKIM is not the only thing that can be reputation washed, SPF can as well.=C2=A0 821.FROM rewriting is more common, so there are work-arounds.=C2=A0 OTOH, SPF doesn't survive forwarding, but with ARC you can forward it.=C2=A0 DKIM+A-R wou= ld only work for a single hop, and lead to some complication compared to the other DKIM signatures already on the message.

By definition a message hitting the front door of the destination domain (via an MX record) sees the DKIM signatures in the message and can process them at that point, or at some point before other manglers get a hold of the message. I don't see why we should car= e at all about what happens beyond the destination domain's front door because that's their problem not ours. The entire point of DKIM is the inter-domain case, not intra-domain.


My point is that for large organizations, the dif= ference between inter-domain and intra-domain becomes much weaker.=C2=A0 An= d I think we're interested in the entire mail ecosystem, which would
include passing such information between intra-domain email vendors= .
With ARC, we can instead say "trust this arc admd"= and have the data passed directly, and also work around the DKIM breakage.

But ARC suffers the same breakage with the ARC-Signature. And if the ARC-Signature is broken, you can't trust the sealed data because that's a trivial cut and paste attack as far as I can see= . So I'm just not seeing how this is any better than just a plain old DKIM-Signature with the old auth-res renamed and signed since you can already for 15 years trust signing intermediaries or not.
=

ARC requires the last AMS to be valid for the c= hain to be intact, yes.=C2=A0 It does not require that all AMS be valid.=C2= =A0 That does mean that content wise, only the last AMS has a strong owners= hip of the message.=C2=A0 ARC in this case does not have the same strength = as DKIM.
=C2=A0
=20
As for another comment in the thread about adding two signatures per hop, there was a suggestion that it could be replaced with a single signature per hop near last call with some loss of information (maybe), but it was decided to move forward with the existing solution that already had several implementations and was experimental anyways.

As I said elsewhere, since this is an active experiment and it's already been a year, it might be good to start documenting what the experiment is teaching us. I still after many messages have no clue what what ARC does that DKIM+old-auth-res cannot beyond tying the authres and signature together. It would be nice to know in a quantitative way why that is important, as well as any other things that cannot be done with DKIM+old-auth-res.

I've cited a number of definitional reasons why your sche= me would not work, I'm unclear what quantitative information would chan= ge that fact.=C2=A0 ARC was designed to actually handle the use case you= 9;re talking about without breaking in obvious ways.=C2=A0 What the ARC exp= eriment is actually asking is whether the added information is useful.=C2= =A0 That information has been provided at various points, and
cer= tainly we should do so again, but adoption has been slow.=C2=A0 That may me= an the experiment will fail.

At Google with limite= d adoption externally and without us even doing all of the things with it t= hat we originally wanted, it has been useful in a number of corner cases an= d flows.=C2=A0 That is not sufficient
for the ecosystem at large,= of course, we need adoption and better usage to see at scale.

In fact since I expect that most signature breaking intermediaries DKIM resign the messages (and if they don't thay aren't going to do ARC either), it would be very simple to chronicle how the two approaches differ in efficacy. The same reputation look for ARC can be done for DKIM too, after all.

When the dmarc-apocalypse happened, relatively few maili= ng list hosters DKIM signed their messages... and I don't think any int= erdomain relays do for the reasons I keep citing.
ARC and DKIM ma= y be similarly technically, but they are meant to impart different informat= ion and be used in different ways, they are not the same.

BTW: i can understand not wanting to touch DKIM or AUTH-RES proper for an experiment, but a standards track document should really consider just adding the binding tag to DKIM and Auth-res. They were both designed to be able to do that.

=
A-R was not designed to allow arbitrary tags, only ones for specific c= ases. DKIM was designed for new tags, but adding them won't automatical= ly change how systems are interpreting them today.

Brandon=C2=A0
--000000000000c27b4c05b5abb59d-- From nobody Fri Dec 4 15:25: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 9DD453A1037 for ; Fri, 4 Dec 2020 15:25:21 -0800 (PST) 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 GY4F2Nus469M for ; Fri, 4 Dec 2020 15:25:20 -0800 (PST) Received: from mail-pf1-x42d.google.com (mail-pf1-x42d.google.com [IPv6:2607:f8b0: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 5FEA23A1034 for ; Fri, 4 Dec 2020 15:25:20 -0800 (PST) Received: by mail-pf1-x42d.google.com with SMTP id t7so4821287pfh.7 for ; Fri, 04 Dec 2020 15:25:20 -0800 (PST) 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=kncGKU131C/tZrlKpYOhlVkAHVVFO/nGguNLLfe4h1s=; b=X7k0UZHfIXVjxvZHc8gagZ2IifxPyh7a1dLjq+VXTREcTjmZ4ee7wsxBA/jtyArQo+ EilXEJo0bxZ0tGW7YT3hpzrUaQDwKZac4Opi4tY87DI1+9HHsdt6zDV1J+3FjujDONH+ m87zr2y13kfTuzXllIebqY0SNxZwO2oTuzCYPFzWvtK4RwoWB79Sq6gSqNciC+RzN/kG x9GJ32rTbiCdrWUr7WplqxJdD0Xr7xMioX0YayaV8Fgly58i86sgRO6kVdNtl3CFXMdM j+ggwucp6ZZrQBRuLyplB1FLoFr9QnSAN2B/aGQmj4j55Abf4uMGu0+U0O9nWy1ZInWP wTbQ== 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=kncGKU131C/tZrlKpYOhlVkAHVVFO/nGguNLLfe4h1s=; b=YB/0/3ojheFjPimrSzIUF20vjM0+VeTUgBkde+dTLHwMygL/c52EDJsbsz+OBF8NxP stWRVgwBaY5nFpbX9GTM1lvzdOX7ZEqiBLp87aeDSwfS5ivzRbKVRdmyfEFAzV9TQ0QK HvE8OtXnhvIRtOXT2x1P/VIxN1DsSOMiCoG9ujs2J3R+XpuGe2S3AQMlFZiVYuQ5zZGx 0ueqQE4I7Lx5he/9okzFqwScnAFI6p+a2q+UBLPtoTJZG3AlvUpQlkRJCtMnHKtlt0Ze bfgCEzHcpu9TSld8k7B0Gvk3BkP7iAJfKDuuLInjOzhtJm5FL4GTL2IwsBgc5trtoAUN rpEQ== X-Gm-Message-State: AOAM532SgXlgsE69E96Lx2+T0/+Ij0LumTMHpqhfknjtGbo3xmk2k2J6 FTVfQ3XmglGksTZGBZmgfTRP2qh78R8= X-Google-Smtp-Source: ABdhPJycjIpSwUoUxjgtWfdQC3sClRXGAKxhP3wBR9nQc491zU5TSFZA1XLBKH4iONjjIGYNdZ43Ag== X-Received: by 2002:a63:4c41:: with SMTP id m1mr9462007pgl.427.1607124319620; Fri, 04 Dec 2020 15:25:19 -0800 (PST) Received: from [192.168.0.109] (c-24-130-62-181.hsd1.ca.comcast.net. [24.130.62.181]) by smtp.gmail.com with ESMTPSA id v186sm5777885pfb.152.2020.12.04.15.25.18 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 04 Dec 2020 15:25:19 -0800 (PST) To: Michael Thomas , dmarc@ietf.org References: <134860ee-5fbf-2fb3-a5b3-4be68806ab22@mtcc.com> <7224575d-685f-5020-073e-c1880acecc88@mtcc.com> <7e459496-61f8-ddcd-713c-3b6be448090c@gmail.com> <2cecceac-1add-44ec-6e16-e157fee293fe@mtcc.com> <5a577765-4a0d-e1bf-5321-dfeff19d107e@gmail.com> <40d7e78e-7026-c65c-383c-df4e3c537de3@mtcc.com> <6fae9ca6-d8ea-1d62-4156-249191029cc3@gmail.com> <80f9963e-20bf-cdfe-cf3b-cda7b2ed08ab@mtcc.com> From: Dave Crocker Message-ID: <6dea9912-83fd-b981-adca-4e6c81047b92@gmail.com> Date: Fri, 4 Dec 2020 15:25:16 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] is DMARC informational? X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 04 Dec 2020 23:25:22 -0000 On 12/4/2020 3:11 PM, Michael Thomas wrote: > Is it really that hard to summarize why the decision was made and what > changed in the bis version? I really don't understand this snipe hunt. You ask a series of basic question and get a string of responses, which point you to easily-found answers, and you call this a practical joke.    On the offchance you don't mean one that you've instigated, please explain. d/ -- Dave Crocker dcrocker@gmail.com 408.329.0791 Volunteer, Silicon Valley Chapter American Red Cross dave.crocker2@redcross.org From nobody Fri Dec 4 15:27: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 07B373A1037 for ; Fri, 4 Dec 2020 15:27:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.652 X-Spam-Level: X-Spam-Status: No, score=-1.652 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mtcc-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4SP55rfdN8Wi for ; Fri, 4 Dec 2020 15:27:47 -0800 (PST) Received: from mail-pl1-x629.google.com (mail-pl1-x629.google.com [IPv6:2607:f8b0:4864:20::629]) (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 DE1913A1034 for ; Fri, 4 Dec 2020 15:27:47 -0800 (PST) Received: by mail-pl1-x629.google.com with SMTP id b23so3991616pls.11 for ; Fri, 04 Dec 2020 15:27:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mtcc-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=+8nXe4/GsKbJH+L5F32yRjvOhJ2p4rTqDU9wxYaynIo=; b=VC1ucabctd+J6d86J7DE1IrIGhjw/tdsV7sg0+wRbFEwwSmE1DbMXba5bEK6bDzrDQ CgHWU9RyzlBRE7EjoCsgdC77/dKrz+XC0QvoWVIBAEZ0SeQAXHRwHayRM2Zc6X6RUjSr Ujr7oy88nl3nKjTvGIEO7X7olwAGuFYhjFdILDyiJuBiXN5Hc/ssqkzraK8UWjgwrMlt FH/YOJoTSYWCgdAOAVo+ieDZKm4Xzc4Jo0aF8SbqLX4hg3SQXOZL04kEa1NlkoMF2lN7 69QEGuKbI+VoJuaA+o+VMhsx6d+elHpLTFBUfHsLeSv3nh4SMNPYiacv+pa9ac2MqqYZ FFqw== 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=+8nXe4/GsKbJH+L5F32yRjvOhJ2p4rTqDU9wxYaynIo=; b=W5XfrGN3afnP6MTazSnjIQzCZQr/+qnhYfI0UH0u3Rk4P0C/ZLpw/mXuiCqyMTBrgI 9dNjGtGL6mYw1UIEKIATQjeU62TNSSl14cTu3vVM+FtZhL3+fbVLI6WhBYTV2ozuC5Ve LQmBCblUfqEWd5VY7y84sALBFHWeczDUvpOPaVS4fnu5bDmLjzFY+iHW6ih1rPws6vOq OY7ljNWeNVmErcPp5Xl2wMdN6Oz76msTrcOtGlO6hYOizG9snRCbvcnzFUOgH+zcNNIU wn/ecY99G+hkCVQG28PONb13SR7Sj867+we8qQyMD2Ekbaze2cbDtB6/pfVXU8W+Js/O T3HA== X-Gm-Message-State: AOAM530lKe2ES7OabO2j7PMfSHB7iAmCQBXJ3fcpjCFIZdLGo2YlaSjB tu1Har/Snrzj1N3ur9dbktpk/xsES0LFHw== X-Google-Smtp-Source: ABdhPJyAl4qDp7ufVPiDLv+sbuoOhAqR75rQGLOArTJmb9BRilN2y6mXY6OYsAhel9nyB0PZSX400A== X-Received: by 2002:a17:902:aa04:b029:d8:b7a8:6a3e with SMTP id be4-20020a170902aa04b02900d8b7a86a3emr5940945plb.58.1607124466869; Fri, 04 Dec 2020 15:27:46 -0800 (PST) Received: from mike-mac.lan (107-182-42-33.volcanocom.com. [107.182.42.33]) by smtp.gmail.com with ESMTPSA id u6sm6050399pfb.197.2020.12.04.15.27.45 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 04 Dec 2020 15:27:46 -0800 (PST) To: Dave Crocker , dmarc@ietf.org References: <134860ee-5fbf-2fb3-a5b3-4be68806ab22@mtcc.com> <7224575d-685f-5020-073e-c1880acecc88@mtcc.com> <7e459496-61f8-ddcd-713c-3b6be448090c@gmail.com> <2cecceac-1add-44ec-6e16-e157fee293fe@mtcc.com> <5a577765-4a0d-e1bf-5321-dfeff19d107e@gmail.com> <40d7e78e-7026-c65c-383c-df4e3c537de3@mtcc.com> <6fae9ca6-d8ea-1d62-4156-249191029cc3@gmail.com> <80f9963e-20bf-cdfe-cf3b-cda7b2ed08ab@mtcc.com> <6dea9912-83fd-b981-adca-4e6c81047b92@gmail.com> From: Michael Thomas Message-ID: Date: Fri, 4 Dec 2020 15:27:44 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 MIME-Version: 1.0 In-Reply-To: <6dea9912-83fd-b981-adca-4e6c81047b92@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] is DMARC informational? X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 04 Dec 2020 23:27:49 -0000 On 12/4/20 3:25 PM, Dave Crocker wrote: > On 12/4/2020 3:11 PM, Michael Thomas wrote: >> Is it really that hard to summarize why the decision was made and >> what changed in the bis version? I really don't understand this snipe >> hunt. > > > You ask a series of basic question and get a string of responses, > which point you to easily-found answers, and you call this a practical > joke.    On the offchance you don't mean one that you've instigated, > please explain. > A bunch of non-responsive responses. If you didn't feel like answering the question asked you could have just kept scrolling. I didn't ask for pointers, after all. Mike From nobody Fri Dec 4 15:28: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 19EEE3A1069 for ; Fri, 4 Dec 2020 15:27:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.999 X-Spam-Level: X-Spam-Status: No, score=-16.999 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, URI_HEX=0.1, URI_NOVOWEL=0.5, 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 RLeSycj4qGQy for ; Fri, 4 Dec 2020 15:27:56 -0800 (PST) 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 D57533A1047 for ; Fri, 4 Dec 2020 15:27:55 -0800 (PST) Received: by mail-vs1-xe36.google.com with SMTP id w18so4194176vsk.12 for ; Fri, 04 Dec 2020 15:27:55 -0800 (PST) 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=8+B9EAkTBov26HRAoCxw7zaIrP3TrB3KZlrsx52MZSM=; b=UgvOlJFCsEmiTqlYRfBKqYgGu3z07v0HhNvmjC6Gm+8vP/Uep9lf/VhdEpdW8l5JQW UcmpxIMsq/N6G97egar+y/NkdcrloYtiJ2hT2KpBBWlhnLxRiBMZdMGqCiCch76gB04k Bhi15REZqlTqlV/ZJ5FjOjYveuiz6Nmnk8ITqqCyG7mx594+x/vbg6l1jf8QpGcggQAx VNswrFo3iTTQuqjVXDn3uDoCMjjaUTEpX2WJqfHHKLDtu+iLmeigImHRUMTC6GHbx3JB Vd5DJjnv1PGITB8o5WxflP9tJL2AH850NSRZ6j3rhu8yr4h84hDrGrMtE/DRODgj9BIq IgWA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=8+B9EAkTBov26HRAoCxw7zaIrP3TrB3KZlrsx52MZSM=; b=WhbYfYRPC+VTx9us2ov8YAcLOuy/riMDN1dLGG9LOPsj9biWfjelGYjKeCbLVIthM4 sknRwm1pFjIZLbTV+A4pBoOxja7a5iqHsDIDRHEsaRvqaY8YUQLnNIxQs7fFA/SfW345 iC2mTMAXhUTrnTnRg9Ez9tbnjhR9LxWevplqNTLxTfUb7i2pUlL/8ehEj7L7PFRRqQIa BtN9aS10G8IP1gHnXdgVC0GmAhsqZXt439cYMsHTcg/bgNIeBnyMJ7Ww06+/PBQZyzcz rAHUJ1szrgP1ErmWrw5O7xqPTLmioyoQGTHwUm8LoW+VvW+bzffoQQQxBXenHjQBF9xv hxKg== X-Gm-Message-State: AOAM531DtYsRvxNDYpJvBJA13vg12M2LrntkcAUojJoKpDPT7CGuVuaV n8Ho5kX1Err1BA+dSsjQ+c7HpVV2jfFdNdGJ/GkUAjRyIQ== X-Google-Smtp-Source: ABdhPJwmm653cirhk3gxqnAXumPYTISNVllU9o0UUAp1K3yEMWxveE7MyX3n1xW65nzmF6mO3VqORz48K7gMRnlC9mA= X-Received: by 2002:a67:e918:: with SMTP id c24mr6544878vso.55.1607124474574; Fri, 04 Dec 2020 15:27:54 -0800 (PST) MIME-Version: 1.0 References: <20201124020453.AFDC027CE5C8@ary.qy> <1eed8278-4efa-4abc-15e0-2efcf014e82e@mtcc.com> <446d491b-100a-9813-6463-2294f67bbda7@mtcc.com> <4190de2d-9f17-06d5-6354-30c989eecd4a@mtcc.com> <17d886fd-49fd-28d8-f8e4-7caf2e85919c@taugh.com> <8bc3c7ad-2a42-3eed-524c-8c50b16131c2@mtcc.com> <42178950-1ac3-27b4-a981-155fd9117969@taugh.com> <70bd5e9-f0e8-3bdf-c5f0-6428841e1577@iecc.com> <162586f5-d565-0e4f-955d-8ceca1d569d2@mtcc.com> In-Reply-To: <162586f5-d565-0e4f-955d-8ceca1d569d2@mtcc.com> From: Brandon Long Date: Fri, 4 Dec 2020 15:27:41 -0800 Message-ID: To: Michael Thomas Cc: "John R. Levine" , "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="0000000000006b1d9605b5abd3d4" Archived-At: Subject: Re: [dmarc-ietf] ARC questions X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 04 Dec 2020 23:28:06 -0000 --0000000000006b1d9605b5abd3d4 Content-Type: text/plain; charset="UTF-8" I'm pretty sure I explained what the X-Google-DKIM-Signature was in this or related threads. It was part of the original attempt at ARC, which was X-Original-Authentication-Results. Adding just an XOAR header was not sufficient, we had to have reason to trust it, so we added the signature. We didn't re-use the existing DKIM-Signature header name because that header was already used by DMARC and had a bunch of other uses that we didn't want to use. And our own coding error while doing it meant that we validated that point... Turns out the signature was done re-using the existing DKIM code, which didn't sign the extra X-Google- at the beginning... so just stripping that off would still pass verification. And we originally signed with d=google.com, so people could relay mail through us, remove the X-Google- and send it again and phish people since it was validly signed by Google. So, we switched the domain to a domain that never sends email to work around that security issue. So yes, that's a way to work around some of the issues if we wanted to pursue the DKIM+A-R, just have everyone sign with a different domain that you don't use for mail. That seems heavier weight to me, but that would be a single-hop solution. I think we did discuss this in the early meetings and found the ARC proposal provided more (multi-hop) and less complicated (no new domains). There's also a phishing design challenge when picking a domain to represent you in a limited way. Brandon On Wed, Dec 2, 2020 at 6:58 PM Michael Thomas wrote: > if you're trying to make a point about the bloat, you might actually get > your facts straight. ARC adds an additional DKIM signature and a Seal. i > have no idea what a X-Google-DKIM-Signature is and is not relevant. > > Mike > > On 12/2/20 6:55 PM, John R. Levine wrote: > >> PS: you're adding X-Google-DKIM-Signature which nobody knows what its > >> utility is to your bloat total for dramatic effect. > > > > Um, it was there when your message arrived here. Complain to your > > mail provider. > > > >> On 12/2/20 6:33 PM, John R Levine wrote: > >>> On Wed, 2 Dec 2020, Michael Thomas wrote: > >>>>> But why bother? The IANA header field registry currently has 419 > >>>>> entries. Why is it a crisis if it increases to 422 rather than 420? > >>>> > >>>> It does a lot more than that: > >>> > >>> We've been through this all before and none of these are > >>> persuasive. For > >>> example: > >>> > >>>> 3) It adds a lot more bloat to the headers > >>> > >>> The message you just sent arrived with 4600 bytes of header (see > >>> below) and under 2K of text. Copies that went through the dmarc > >>> mailing list probably had at least another 1K of header. > >>> > >>> If header bloat were ever an issue, it hasn't been for decades. > >>> > >>> R's, > >>> John > >>> ---- snip --- > >>> Return-Path: > >>> X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on > gal.iecc.com > >>> X-Spam-Level: X-Spam-Status: No, score=-1.5 required=4.4 > >>> tests=BAYES_00,DCC_REPUT_00_12, > >>> DKIM_SIGNED,DKIM_VALID,NICE_REPLY_A,RDNS_NONE,SPF_HELO_NONE > >>> autolearn=no autolearn_force=no version=3.4.4 > >>> Delivered-To: johnl@iecc.com > >>> Received: (qmail 70731 invoked by uid 1014); 2 Dec 2020 23:30:07 -0000 > >>> Delivered-To: virtual-taugh-johnl@taugh.com > >>> Received: (qmail 70729 invoked from network); 2 Dec 2020 23:30:07 -0000 > >>> Authentication-Results: iecc.com; spf=pass > >>> spf.mailfrom=mike@fresheez.com spf.helo=mail-pl1-x62a.google.com > >>> smtp.remote-ip="2607:f8b0:4864:20::62a"; dkim=pass > >>> header.d=mtcc-com.20150623.gappssmtp.com header.s=20150623 > >>> header.a=rsa-sha256 header.b="vvoZ+Loe" > >>> Received: from mail-pl1-x62a.google.com > ([IPV6:2607:f8b0:4864:20::62a]) > >>> by mail1.iecc.com ([IPV6:2001:470:1f07:1126:33:5370:616d:6d31]) > >>> with ESMTPS via TCP6 (port 38853/25) id 665297367 > >>> tls TLS1.3_ECDHE_RSA_AES_128_GCM_AEAD sni mx1.taugh.com; 02 Dec > >>> 2020 23:30:06 -0000 > >>> Received: by mail-pl1-x62a.google.com with SMTP id 4so91499plk.5 > >>> for ; Wed, 02 Dec 2020 15:30:05 -0800 (PST) > >>> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; > >>> d=mtcc-com.20150623.gappssmtp.com; s=20150623; > >>> h=subject:to:cc:references:from:message-id:date:user-agent > >>> :mime-version:in-reply-to:content-transfer-encoding:content-language; > >>> bh=frJndGBg4PljdPRXFB1KqYuhqqDFqbuyeJjhznmBtNo=; > >>> b=vvoZ+Loew2ueICysZfzHi5UwJ3jXLN5dX+kyHN3HI91ZMJWMq7cym6dw1XQ9zaHvar > >>> KWobHhYgPlIURrzw5+sM1lArZM0+S8zElTI9oJicfts5VpsuYtc3kGzpFO58DlGQMzji > >>> +Bshah0JzXltImvCLjzUhHXHOLYvfA/Hk9lwY5XD904cTcBo4UfTKvenfFv3yLyBc4k3 > >>> l61UDIWK7HRcdixAnDYx7zJLZaO3qcbPOwkG48uqCoMDIJVhcBndL82W/JflTPy4EB9S > >>> VydV+ABOODKddInyT2i5+/cTXS1B66NWYHF/Auh1UqRkxB/+H5T//oXYkKWqXolceqkS > >>> Y3Nw== > >>> 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=frJndGBg4PljdPRXFB1KqYuhqqDFqbuyeJjhznmBtNo=; > >>> b=EiCvgdUtIHSRQXtcFgoSdo/YgcWiu1mxFOdlQ/tDw8nd2ipjfcUBNlRSW9ygClV9vu > >>> TBZpT6xrU/F0xLA6fq9Tt51Z4S1VSgDSOCt1Ut8+oLzyBXkDCjQ3j8rByKqPkRvivOap > >>> 82rO+tMd5J/4SMAAPGmJ28WAq+E7J4EJknvVu1LUOEiTERnAbmT9ZK/eTEKPjQGx0msa > >>> GMCKzawKzSfLMvOIqaKoPUmxPyrtEnEUizEPer7/aXZ0pXrUTHQ82984GTYqSdKDoYIS > >>> T+59dBxbPY9KwT33oih+1slVUSLBEbzUigK3wj4yA/71KTvr76KCUEaU8cYI6/TYcszz > >>> 2CWA== > >>> X-Gm-Message-State: > >>> AOAM530XUwEgBdQ2e02rPshm7iyXROuyhTJeAndRJAFtQO8oX1JUEgsD > >>> chdQCnyR1XB3fAEw5oIqGysS4Q== > >>> X-Google-Smtp-Source: > >>> > ABdhPJzQUtiWyUp4dVxdii6hT+h4YBukyVaoJ5846n5Di6IUaEwxKrufF/3Atxm7lejww+dr4k5xIw== > >>> X-Received: by 2002:a17:90a:c4f:: with SMTP id > >>> u15mr287214pje.177.1606951804840; > >>> Wed, 02 Dec 2020 15:30:04 -0800 (PST) > >>> Return-Path: > >>> Received: from mike-mac.lan (107-182-42-33.volcanocom.com. > >>> [107.182.42.33]) > >>> by smtp.gmail.com with ESMTPSA id > >>> x7sm158495pfn.85.2020.12.02.15.30.03 > >>> (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); > >>> Wed, 02 Dec 2020 15:30:04 -0800 (PST) > >>> Subject: Re: [dmarc-ietf] ARC questions > >>> To: John R Levine , Brandon Long > >>> Cc: IETF DMARC WG > >>> References: <20201124020453.AFDC027CE5C8@ary.qy> > >>> > >>> > >>> > >>> > >>> <1eed8278-4efa-4abc-15e0-2efcf014e82e@mtcc.com> > >>> > >>> <446d491b-100a-9813-6463-2294f67bbda7@mtcc.com> > >>> > >>> <4190de2d-9f17-06d5-6354-30c989eecd4a@mtcc.com> > >>> <17d886fd-49fd-28d8-f8e4-7caf2e85919c@taugh.com> > >>> > >>> > >>> From: Michael Thomas > >>> Message-ID: <8bc3c7ad-2a42-3eed-524c-8c50b16131c2@mtcc.com> > >>> Date: Wed, 2 Dec 2020 15:30:01 -0800 > >>> User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) > >>> Gecko/20100101 Thunderbird/78.5.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 > >> > >> > > > > Regards, > > John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for > > Dummies", > > Please consider the environment before reading this e-mail. > https://jl.ly > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > --0000000000006b1d9605b5abd3d4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I'm pretty sure I explained what the X-Google-DKI= M-Signature was in this or related threads.=C2=A0 It was
part of = the original attempt at ARC, which was X-Original-Authentication-Results.= =C2=A0 Adding just
an XOAR header was not sufficient, we had to h= ave reason to trust it, so we added the signature.
We didn't = re-use the existing DKIM-Signature header name because that header was alre= ady used
by DMARC and had a bunch of other uses that we didn'= t want to use.

And our own coding error while doin= g it meant that we validated that point... Turns out the signature
was done re-using the existing DKIM code, which didn't sign the extra= X-Google- at the beginning...
so just stripping that off would s= till pass verification.=C2=A0 And we originally signed with d=3Dgoogle.com,
so people could relay mail thr= ough us, remove the X-Google- and send it again and phish people
= since it was validly signed by Google.=C2=A0 So, we switched the domain to = a domain that never sends
email to work around that security issu= e.

So yes, that's a way to work around some of= the issues if we wanted to pursue the DKIM+A-R,
just have everyo= ne sign with a different domain that you don't use for mail.=C2=A0 That= seems heavier
weight to me, but that would be a single-hop solut= ion.=C2=A0 I think we did discuss this in the early meetings
and = found the ARC proposal provided more (multi-hop) and less complicated (no n= ew domains).=C2=A0 There's
also a phishing design challenge w= hen picking a domain to represent you in a limited way.

Brandon

On Wed, Dec 2, 2020 at 6:58 PM Michael Thomas <mike@mtcc.com> wrote:
if you're trying to make a point abou= t the bloat, you might actually get
your facts straight. ARC adds an additional DKIM signature and a Seal. i have no idea what a X-Google-DKIM-Signature is and is not relevant.

Mike

On 12/2/20 6:55 PM, John R. Levine wrote:
>> PS: you're adding X-Google-DKIM-Signature which nobody knows w= hat its
>> utility is to your bloat total for dramatic effect.
>
> Um, it was there when your message arrived here.=C2=A0 Complain to you= r
> mail provider.
>
>> On 12/2/20 6:33 PM, John R Levine wrote:
>>> On Wed, 2 Dec 2020, Michael Thomas wrote:
>>>>> But why bother?=C2=A0 The IANA header field registry c= urrently has 419
>>>>> entries. Why is it a crisis if it increases to 422 rat= her than 420?
>>>>
>>>> It does a lot more than that:
>>>
>>> We've been through this all before and none of these are <= br> >>> persuasive.=C2=A0 For
>>> example:
>>>
>>>> 3) It adds a lot more bloat to the headers
>>>
>>> The message you just sent arrived with 4600 bytes of header (s= ee
>>> below) and under 2K of text.=C2=A0 Copies that went through th= e dmarc
>>> mailing list probably had at least another 1K of header.
>>>
>>> If header bloat were ever an issue, it hasn't been for dec= ades.
>>>
>>> R's,
>>> John
>>> ---- snip ---
>>> Return-Path: <mike@fresheez.com>
>>> X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on gal.iecc.= com
>>> X-Spam-Level: X-Spam-Status: No, score=3D-1.5 required=3D4.4 <= br> >>> tests=3DBAYES_00,DCC_REPUT_00_12,
>>> =C2=A0=C2=A0=C2=A0=C2=A0DKIM_SIGNED,DKIM_VALID,NICE_REPLY_A,RD= NS_NONE,SPF_HELO_NONE
>>> =C2=A0=C2=A0=C2=A0=C2=A0autolearn=3Dno autolearn_force=3Dno ve= rsion=3D3.4.4
>>> Delivered-To: johnl@iecc.com
>>> Received: (qmail 70731 invoked by uid 1014); 2 Dec 2020 23:30:= 07 -0000
>>> Delivered-To: virtual-taugh-johnl@taugh.com
>>> Received: (qmail 70729 invoked from network); 2 Dec 2020 23:30= :07 -0000
>>> Authentication-Results: iecc.com; spf=3Dpass
>>> spf.mailfrom=3Dmike@fresheez.com spf.helo=3Dmail-pl1-x62a.google.com=
>>> smtp.remote-ip=3D"2607:f8b0:4864:20::62a"; dkim=3Dpa= ss
>>> header.d=3Dmtcc-com.20150623.gappssmtp.com he= ader.s=3D20150623
>>> header.a=3Drsa-sha256 header.b=3D"vvoZ+Loe"
>>> Received: from mail-pl1-x62a.google.com ([IPV6:2607:= f8b0:4864:20::62a])
>>> =C2=A0 by mail1.iecc.com ([IPV6:2001:470:1f07:1126:33:5370:616= d:6d31])
>>> =C2=A0 with ESMTPS via TCP6 (port 38853/25) id 665297367
>>> =C2=A0 tls TLS1.3_ECDHE_RSA_AES_128_GCM_AEAD sni mx1.taugh.com;= 02 Dec
>>> 2020 23:30:06 -0000
>>> Received: by mail-pl1-x62a.google.com with SMTP id= 4so91499plk.5
>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 for <johnl@taugh.com>; Wed, 02 = Dec 2020 15:30:05 -0800 (PST)
>>> DKIM-Signature: v=3D1; a=3Drsa-sha256; c=3Drelaxed/relaxed; >>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 d=3Dmt= cc-com.20150623.gappssmtp.com; s=3D20150623;
>>> h=3Dsubject:to:cc:references:from:message-id:date:user-agent >>> :mime-version:in-reply-to:content-transfer-encoding:content-la= nguage;
>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 bh=3DfrJndGBg4PljdP= RXFB1KqYuhqqDFqbuyeJjhznmBtNo=3D;
>>> b=3DvvoZ+Loew2ueICysZfzHi5UwJ3jXLN5dX+kyHN3HI91ZMJWMq7cym6dw1X= Q9zaHvar
>>> KWobHhYgPlIURrzw5+sM1lArZM0+S8zElTI9oJicfts5VpsuYtc3kGzpFO58Dl= GQMzji
>>> +Bshah0JzXltImvCLjzUhHXHOLYvfA/Hk9lwY5XD904cTcBo4UfTKvenfFv3yL= yBc4k3
>>> l61UDIWK7HRcdixAnDYx7zJLZaO3qcbPOwkG48uqCoMDIJVhcBndL82W/JflTP= y4EB9S
>>> VydV+ABOODKddInyT2i5+/cTXS1B66NWYHF/Auh1UqRkxB/+H5T//oXYkKWqXo= lceqkS
>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Y3Nw=3D=3D >>> X-Google-DKIM-Signature: v=3D1; a=3Drsa-sha256; c=3Drelaxed/re= laxed;
>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 d=3D1e100.net; s=3D20161= 025;
>>> h=3Dx-gm-message-state:subject:to:cc:references:from:message-i= d:date
>>> :user-agent:mime-version:in-reply-to:content-transfer-encoding=
>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 :content-lang= uage;
>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 bh=3DfrJndGBg4PljdP= RXFB1KqYuhqqDFqbuyeJjhznmBtNo=3D;
>>> b=3DEiCvgdUtIHSRQXtcFgoSdo/YgcWiu1mxFOdlQ/tDw8nd2ipjfcUBNlRSW9= ygClV9vu
>>> TBZpT6xrU/F0xLA6fq9Tt51Z4S1VSgDSOCt1Ut8+oLzyBXkDCjQ3j8rByKqPkR= vivOap
>>> 82rO+tMd5J/4SMAAPGmJ28WAq+E7J4EJknvVu1LUOEiTERnAbmT9ZK/eTEKPjQ= Gx0msa
>>> GMCKzawKzSfLMvOIqaKoPUmxPyrtEnEUizEPer7/aXZ0pXrUTHQ82984GTYqSd= KDoYIS
>>> T+59dBxbPY9KwT33oih+1slVUSLBEbzUigK3wj4yA/71KTvr76KCUEaU8cYI6/= TYcszz
>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 2CWA=3D=3D >>> X-Gm-Message-State:
>>> AOAM530XUwEgBdQ2e02rPshm7iyXROuyhTJeAndRJAFtQO8oX1JUEgsD
>>> =C2=A0=C2=A0=C2=A0=C2=A0chdQCnyR1XB3fAEw5oIqGysS4Q=3D=3D
>>> X-Google-Smtp-Source:
>>> ABdhPJzQUtiWyUp4dVxdii6hT+h4YBukyVaoJ5846n5Di6IUaEwxKrufF/3Atx= m7lejww+dr4k5xIw=3D=3D
>>> X-Received: by 2002:a17:90a:c4f:: with SMTP id
>>> u15mr287214pje.177.1606951804840;
>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Wed, 02 Dec 2020 15= :30:04 -0800 (PST)
>>> Return-Path: <mike@fresheez.com>
>>> Received: from mike-mac.lan (107-182-42-33.volcanoco= m.com.
>>> [107.182.42.33])
>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 by smtp.gmail.com w= ith ESMTPSA id
>>> x7sm158495pfn.85.2020.12.02.15.30.03
>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (version=3DTLS1_3 c= ipher=3DTLS_AES_128_GCM_SHA256 bits=3D128/128);
>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Wed, 02 Dec 2020 15= :30:04 -0800 (PST)
>>> Subject: Re: [dmarc-ietf] ARC questions
>>> To: John R Levine <johnl@taugh.com>, Brandon Long <blong@google.com>
>>> Cc: IETF DMARC WG <dmarc@ietf.org>
>>> References: <20201124020453.AFDC027CE5C8@ary.qy>
>>> =C2=A0<cd855b53-d9bd-3412-3bd5-dc4b7720dc5c@mtcc.co= m>
>>> =C2=A0<CABa8R6s0bfs87Fu9eOq_R3= WH1pngauVXrw3RSPe9iWWCtf3AmQ@mail.gmail.com>
>>> =C2=A0<c954eadd-5c85-c0d9-2168-8a42de506b72@mtcc.co= m>
>>> =C2=A0<CABa8R6swzAQLPU=3DxE2tr1W0J5r+w80BSYu= 87_ubMwHaUMgmKvA@mail.gmail.com>
>>> =C2=A0<1eed8278-4efa-4abc-15e0-2efcf014e82e@mtcc.co= m>
>>> =C2=A0<CABa8R6sEk+dHwHjBCKDgcmeT_Z3FymC5+jzy-GGa=3D7gJYvOf5A@mail.gmail= .com>
>>> =C2=A0<446d491b-100a-9813-6463-2294f67bbda7@mtcc.co= m>
>>> =C2=A0<aafa5e78-aff9-8076-b76f-62f5b3a13fc1@taugh.= com>
>>> =C2=A0<4190de2d-9f17-06d5-6354-30c989eecd4a@mtcc.co= m>
>>> =C2=A0<17d886fd-49fd-28d8-f8e4-7caf2e85919c@taugh.= com>
>>> =C2=A0<f785884b-2a3d-a6fe-6bb6-ee792d23ff23@mtcc.co= m>
>>> =C2=A0<d5e9dbe-7d83-d3b1-2aa9-3e3562d3e75@taugh.com<= /a>>
>>> From: Michael Thomas <mike@mtcc.com>
>>> Message-ID: <8bc3c7ad-2a42-3eed-524c-8c50b16131c2@m= tcc.com>
>>> Date: Wed, 2 Dec 2020 15:30:01 -0800
>>> User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:7= 8.0)
>>> =C2=A0Gecko/20100101 Thunderbird/78.5.0
>>> MIME-Version: 1.0
>>> In-Reply-To: <d5e9dbe-7d83-d3b1-2aa9-3e3562d3e75@tau= gh.com>
>>> Content-Type: text/plain; charset=3Dutf-8; format=3Dflowed
>>> Content-Transfer-Encoding: 8bit
>>> Content-Language: en-US
>>
>>
>
> Regards,
> John Levine, john= l@taugh.com, Primary Perpetrator of "The Internet for
> Dummies",
> Please consider the environment before reading this e-mail. https://jl.ly

_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
--0000000000006b1d9605b5abd3d4-- From nobody Fri Dec 4 15: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 565AB3A1044 for ; Fri, 4 Dec 2020 15:30:12 -0800 (PST) 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 Puzks6L_3TkS for ; Fri, 4 Dec 2020 15:30:11 -0800 (PST) Received: from mail-pg1-x533.google.com (mail-pg1-x533.google.com [IPv6:2607:f8b0:4864:20::533]) (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 3D78A3A103C for ; Fri, 4 Dec 2020 15:30:11 -0800 (PST) Received: by mail-pg1-x533.google.com with SMTP id t37so4480474pga.7 for ; Fri, 04 Dec 2020 15:30:11 -0800 (PST) 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=15h3kkPz9MAXJSd3ss/Q0PZYtvBdN5rfwItcpNCu5Ac=; b=hfcclOmwOxZ+lcKk4t/3/Qhq0xcavE5SbCvc3a24bRNT8xNxpFP+mLkWfCtnfKgM9/ tXCxIcYyOXxGYJo45K3fYkubbieNlxKwJUb8yhGTr6BT4xYGEHix0bb9eBtDmznMiatD HVPOAbGQ6Wtvfj06YZ9aehUts8jBCj3BvlVDGQFxas+/9rJP+spputn6qAoG6hCyNCjW zUwHZsTyTPALLHatsiu/jCDLCX4s02wV1DXa9VDE1H3Z0P5crYNX4HO94ZIKCzSjTSR9 ilT4C+gZ/oV2pQFxUQ4wePV86c7ifeNPuyWpuRu7gn2YwDWF+ScTJO0HX8L4OajThvXq 7RWA== 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=15h3kkPz9MAXJSd3ss/Q0PZYtvBdN5rfwItcpNCu5Ac=; b=aYxSoMhG76eWB/Xgwi1/SwivyzaO210BTEWWUQmz5Ot+TCjPq7Oev6PDZxxJQ3nOHk k9a2k/YnBZr302NmJbEOwYmRJyFpuabpPbryGgbMO4b2U18EHFqIsSSvlWd8uE7L8iMQ 9acsxE3Ci12WbzZ6MUzuQyLXCTYUjfl2F+vbviRf045DLIrWqFnQkgK6R5Fpi35Gj0+e F+/6iUdTM0xK2ZtWr+epvbgSzwi3PPXnoL8QNtQP/PEhNJ4bIcIvD1K/Iuoo5o47T+qs 9Lzg07wuF6BrRxVNT8qz4ZQF/j1/QRaZ0Yz4/hmF0DEsRxMq5PCnExZKW2vzmYuwLkFL 2P2Q== X-Gm-Message-State: AOAM5323ke1CYtgaAdfg8Y0HxRVbeAQLl74qrAq9GV50KDWugoBWCjWN QwqDBSAxV8CnpuQtgpC3GFHMUU+NFgI= X-Google-Smtp-Source: ABdhPJzk0c/ZwvWbPnys8cLeAltw8tOiaR1epBfgn5wmpS5rQJ9qFqNknKN1QKjZM1elIn0qhiRpsQ== X-Received: by 2002:a63:1b22:: with SMTP id b34mr9254370pgb.216.1607124610562; Fri, 04 Dec 2020 15:30:10 -0800 (PST) Received: from [192.168.0.109] (c-24-130-62-181.hsd1.ca.comcast.net. [24.130.62.181]) by smtp.gmail.com with ESMTPSA id r68sm5983131pfr.113.2020.12.04.15.30.09 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 04 Dec 2020 15:30:10 -0800 (PST) To: Michael Thomas , dmarc@ietf.org References: <134860ee-5fbf-2fb3-a5b3-4be68806ab22@mtcc.com> <7224575d-685f-5020-073e-c1880acecc88@mtcc.com> <7e459496-61f8-ddcd-713c-3b6be448090c@gmail.com> <2cecceac-1add-44ec-6e16-e157fee293fe@mtcc.com> <5a577765-4a0d-e1bf-5321-dfeff19d107e@gmail.com> <40d7e78e-7026-c65c-383c-df4e3c537de3@mtcc.com> <6fae9ca6-d8ea-1d62-4156-249191029cc3@gmail.com> <80f9963e-20bf-cdfe-cf3b-cda7b2ed08ab@mtcc.com> <6dea9912-83fd-b981-adca-4e6c81047b92@gmail.com> From: Dave Crocker Message-ID: <0628c73b-be8f-8baa-cbed-4e8fbdc443a8@gmail.com> Date: Fri, 4 Dec 2020 15:30:08 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] is DMARC informational? X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 04 Dec 2020 23:30:12 -0000 On 12/4/2020 3:27 PM, Michael Thomas wrote: > A bunch of non-responsive responses. If you didn't feel like answering > the question asked you could have just kept scrolling. I didn't ask > for pointers, after all. The pointers are answers.  If you don't feel like reading the material or reflecting on it, that's a different matter. d/ -- Dave Crocker dcrocker@gmail.com 408.329.0791 Volunteer, Silicon Valley Chapter American Red Cross dave.crocker2@redcross.org From nobody Fri Dec 4 15:34: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 18E003A0E25 for ; Fri, 4 Dec 2020 15:34:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.652 X-Spam-Level: X-Spam-Status: No, score=-1.652 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mtcc-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7fX7yuGbeKTi for ; Fri, 4 Dec 2020 15:34:53 -0800 (PST) Received: from mail-pj1-x1033.google.com (mail-pj1-x1033.google.com [IPv6:2607:f8b0:4864:20::1033]) (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 E78ED3A0E22 for ; Fri, 4 Dec 2020 15:34:52 -0800 (PST) Received: by mail-pj1-x1033.google.com with SMTP id z12so4047445pjn.1 for ; Fri, 04 Dec 2020 15:34:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mtcc-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=IzfZKBuIrkGuaj0ud7MauCqEfH6pu7dQzenwJJ9HZWM=; b=lwJ9jK4gLDkpmPW4NpKXlOjFor4mtu0GhT6VLo0/SpU2RwdYvimiFQCdkiivY+5Kl/ AzNIldx8BS29B9zFrAp5Xku+BHW+3kzDiCzqBFrfiKxhoEVWopIdHtScAYLFAblNvrJo Cw3DReEYuZY/N3v4EoO7+ExeJHfycJkZwoXKh1Tgg5Kj9KtGgj+pxwWYG3xJkuQTEHM+ k50gOTq+IL/ITgl8nXejVsXfIrCzyNmEacrs/8s0ZhgUCAj5yp3KAeqC/AkyeClgAduQ lg2eLlGDxlAQbEsHb+CFpORde+X3wdUHubX+ecwFsUVmQIc11kqH8Q7qisP9D60xK4Cj drKA== 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=IzfZKBuIrkGuaj0ud7MauCqEfH6pu7dQzenwJJ9HZWM=; b=QBslaD5YGXSKmi9uWpOVI7X2PWG28yx/OCk5MiDFymSQsTSJq3pvQrcOO7+hOCmowI wiwlU4CNCWa8Xdm2T7o4IQQsrUz71h/ayaQyN4BtA38IVTw9mAVfoZeRF1jNh1olrpTx kD7Ttx2Kt3n00o8NruoDyYgTyX41syltbQdwZ7LzrtSeezDYvgqm6r0TkuJYx2YEVdzE ZV87Fb5csR6eX+zDX3VUJXoN4SRCOSp3ALECtnKFiQGdRAZgkLVD6KcJgfVHf7DMTIKJ U7jqZiTGjnp+rPiyD76+39DaFb8Nc1TRQxcRjQWisdexqqgbF6Eoy0JE6LSgaLGATUVV 19tw== X-Gm-Message-State: AOAM532jt8mqsShK4yC2Z3EHZOyF1thH1vvxFSe70w7nfjDjFgo7UXbV auE1FLV39LNWoqiyWS7PdFbJDJjJLRh1OA== X-Google-Smtp-Source: ABdhPJzur74iE9fCZ4gAMC58od9cur7BUaQjUxym+R/6qFwVR/nAOXFc9OQXlj2Im2ejOpTRWkjRwg== X-Received: by 2002:a17:902:ec03:b029:d7:c7c2:145a with SMTP id l3-20020a170902ec03b02900d7c7c2145amr6145825pld.33.1607124891992; Fri, 04 Dec 2020 15:34:51 -0800 (PST) Received: from mike-mac.lan (107-182-42-33.volcanocom.com. [107.182.42.33]) by smtp.gmail.com with ESMTPSA id j69sm5915973pfd.37.2020.12.04.15.34.50 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 04 Dec 2020 15:34:51 -0800 (PST) To: Dave Crocker , dmarc@ietf.org References: <134860ee-5fbf-2fb3-a5b3-4be68806ab22@mtcc.com> <7224575d-685f-5020-073e-c1880acecc88@mtcc.com> <7e459496-61f8-ddcd-713c-3b6be448090c@gmail.com> <2cecceac-1add-44ec-6e16-e157fee293fe@mtcc.com> <5a577765-4a0d-e1bf-5321-dfeff19d107e@gmail.com> <40d7e78e-7026-c65c-383c-df4e3c537de3@mtcc.com> <6fae9ca6-d8ea-1d62-4156-249191029cc3@gmail.com> <80f9963e-20bf-cdfe-cf3b-cda7b2ed08ab@mtcc.com> <6dea9912-83fd-b981-adca-4e6c81047b92@gmail.com> <0628c73b-be8f-8baa-cbed-4e8fbdc443a8@gmail.com> From: Michael Thomas Message-ID: Date: Fri, 4 Dec 2020 15:34:49 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 MIME-Version: 1.0 In-Reply-To: <0628c73b-be8f-8baa-cbed-4e8fbdc443a8@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] is DMARC informational? X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 04 Dec 2020 23:34:54 -0000 On 12/4/20 3:30 PM, Dave Crocker wrote: > On 12/4/2020 3:27 PM, Michael Thomas wrote: >> A bunch of non-responsive responses. If you didn't feel like >> answering the question asked you could have just kept scrolling. I >> didn't ask for pointers, after all. > > The pointers are answers.  If you don't feel like reading the material > or reflecting on it, that's a different matter. > There was nothing to "reflect" with the history pointer. It was completely non-responsive. If your intention is not to answer the question, what is your motivation keeping this non-responsive thread alive for a dozen messages? Mike From nobody Fri Dec 4 15:42: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 C94BC3A104C for ; Fri, 4 Dec 2020 15:42:34 -0800 (PST) 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 2fq9cnc-Lwgz for ; Fri, 4 Dec 2020 15:42:33 -0800 (PST) Received: from mail-pj1-x102e.google.com (mail-pj1-x102e.google.com [IPv6:2607:f8b0:4864:20::102e]) (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 0137B3A104B for ; Fri, 4 Dec 2020 15:42:32 -0800 (PST) Received: by mail-pj1-x102e.google.com with SMTP id l23so4090225pjg.1 for ; Fri, 04 Dec 2020 15:42:32 -0800 (PST) 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=HW/By+1tQXwsElU3bjJgULz/w2SCcVTFfECv/WeZI5w=; b=VBYLIdl6hyV6KNy543yBdc88wL7tqUbeGvif3ybebDPfI0rCOEOhOw5XWejUlEsaO7 zPKpPPpmna7eLtBq0Nab9oNVWWb2bHV09eRpBGs/RltA90F/vbECXU9DVtbLkYsypFbG EoEMF53lkJs8tLTjbDucnC4bkFBhTREuPadpmKujRIiuHlIxLjykhK8HZNUXiEa8zRNT yywg3ww5lE4OiBqOAP+mCcouGHQmw+qzXsgmYYR6DW27OV8iQ+T0TW3yrzjOW0gSpvAM CKQrxQMmFVTsYthVVxi0s/Fd07M7Dz0io5sQq5ert44ntdWt9NSbbAo8tQCsBNXxuY+h HunQ== 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=HW/By+1tQXwsElU3bjJgULz/w2SCcVTFfECv/WeZI5w=; b=aC82YYkf3Zc/O3H5jBV8l8aUMq+gMjNfs8tcaxuXO6N5ZYo20aHcJnBRQzIWFk8e5+ Ut2rb7cKl8tXD4AEvFCtC9IXR883VT7ZUJOIML9+Vwvx0P/iQOuAuDNGUDHuJSrZmeD3 7ph3A+iJvd51M/SNMU8FVDJnQPoU0vwAvjyy6tRUtoMPTCJSIScZFlkEEHN3PUEhZj6m kxivM3NZlCGGeeU8M5jx2RhYHror5xNhxiS7BaiXlNouRCt3J7rJVTawZHdrC8Tuv2jd xwSrGA7PVOw+XZGwVi97mOdzKNksoCvPQW5HkYLONcl+Y5A+HAKDJooAyvljbsoOQI9V GTSQ== X-Gm-Message-State: AOAM532Pt6FivUUOXRFmPVOmUbA8swazG2FuuehZl1NxhOmgQrB9QsB8 J2nvV5ILhiu3wrLB/t7udhwUoXCpgKE= X-Google-Smtp-Source: ABdhPJy0eED9jaPXgMjZWtJNPi8eVh77DvCicTmzIlgq+FlyTAy4PQmINMs6JWRcYCyhVmeFpZhBSA== X-Received: by 2002:a17:90a:8406:: with SMTP id j6mr6210110pjn.183.1607125352426; Fri, 04 Dec 2020 15:42:32 -0800 (PST) Received: from [192.168.0.109] (c-24-130-62-181.hsd1.ca.comcast.net. [24.130.62.181]) by smtp.gmail.com with ESMTPSA id t19sm5018300pgk.86.2020.12.04.15.42.31 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 04 Dec 2020 15:42:31 -0800 (PST) To: Michael Thomas , dmarc@ietf.org References: <134860ee-5fbf-2fb3-a5b3-4be68806ab22@mtcc.com> <7224575d-685f-5020-073e-c1880acecc88@mtcc.com> <7e459496-61f8-ddcd-713c-3b6be448090c@gmail.com> <2cecceac-1add-44ec-6e16-e157fee293fe@mtcc.com> <5a577765-4a0d-e1bf-5321-dfeff19d107e@gmail.com> <40d7e78e-7026-c65c-383c-df4e3c537de3@mtcc.com> <6fae9ca6-d8ea-1d62-4156-249191029cc3@gmail.com> <80f9963e-20bf-cdfe-cf3b-cda7b2ed08ab@mtcc.com> <6dea9912-83fd-b981-adca-4e6c81047b92@gmail.com> <0628c73b-be8f-8baa-cbed-4e8fbdc443a8@gmail.com> From: Dave Crocker Message-ID: Date: Fri, 4 Dec 2020 15:42:30 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------AA0AE1A12800E857CF15A32C" Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] is DMARC informational? X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 04 Dec 2020 23:42:35 -0000 This is a multi-part message in MIME format. --------------AA0AE1A12800E857CF15A32C Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 12/4/2020 3:34 PM, Michael Thomas wrote: >> >> The pointers are answers.  If you don't feel like reading the >> material or reflecting on it, that's a different matter. >> > There was nothing to "reflect" with the history pointer. It was > completely non-responsive. It was completely responsive. d/ -- Dave Crocker dcrocker@gmail.com 408.329.0791 Volunteer, Silicon Valley Chapter American Red Cross dave.crocker2@redcross.org --------------AA0AE1A12800E857CF15A32C Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 12/4/2020 3:34 PM, Michael Thomas wrote:

The pointers are answers.  If you don't feel like reading the material or reflecting on it, that's a different matter.

There was nothing to "reflect" with the history pointer. It was completely non-responsive.

It was completely responsive.

d/

-- 
Dave Crocker
dcrocker@gmail.com
408.329.0791

Volunteer, Silicon Valley Chapter
American Red Cross
dave.crocker2@redcross.org
--------------AA0AE1A12800E857CF15A32C-- From nobody Fri Dec 4 16:44: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 4D3BD3A10B5 for ; Fri, 4 Dec 2020 16:44:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.05 X-Spam-Level: X-Spam-Status: No, score=-1.05 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URI_HEX=0.1, URI_NOVOWEL=0.5] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mtcc-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3fYa-TM2pKEI for ; Fri, 4 Dec 2020 16:44:47 -0800 (PST) Received: from mail-pf1-x42f.google.com (mail-pf1-x42f.google.com [IPv6:2607:f8b0:4864:20::42f]) (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 C5C9C3A10B3 for ; Fri, 4 Dec 2020 16:44:47 -0800 (PST) Received: by mail-pf1-x42f.google.com with SMTP id w6so4935509pfu.1 for ; Fri, 04 Dec 2020 16:44:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mtcc-com.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=Si4xaL6CNmr8LU7KJQKirv4Rh5psNwM+JmAZ/wjmYH8=; b=MghmoSnQVL0qIiDCMlBBmLax3e1n5gRmmmYu+w96z2DBRC8yimtNnx+DzUMyHfDabB bER2/OjXUl4GWz4Nm9DrVsUkg0QiiyKFTuKPJao4BUa1k3tAXhgNFTprFaXZDz+x2Nzk bGQjxnsNdj8MiRo3ltcGvP5QyJeX8w45faUMYuEJCOxQqftFg256ylKKVAOauUR+F7wT DnrHQmWz66QQhMLgpRnzBMRiGJhXVNYAaYuIsxgTRernHQ33eXIE6zQAXzDJpjCn5xwV Fz24TyjM/A/0Odyt6OzAGebuJ1P+1bfZkYmSql7teQvBhH+KuxWqDVLI/IKjZbdk2bNS XGcA== 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=Si4xaL6CNmr8LU7KJQKirv4Rh5psNwM+JmAZ/wjmYH8=; b=Dt2QQUaoM2Sjlz7PtJ1Pp6fVms2utPbsYBCaPYQ+e+v7V+AeRsfw1yEum3LOertlnt YQ1WCtwUZMgOefgfnqb6gsl78yH3g+9Bwe10UFyhrhrvPwTJ5aFkFWkziXIQ5kWsfMYH tzYX2aVanxOsvZZMZi/vZ3gDhBZ+6mmfftHEyRssm/widIaAzGTmt8/rNyd9VQyWtZLU rP92w62TJNMv6XbnfNWYd8E70Ng8tfrJF41Lt4WMR3Yi+E++kPFmFkSLHmAjzPvTewra 98KnQYQaxrChWqw+WCQzyMv+DiK6trcwfd9HbIk72hm9xrxG/beZsyQFhqHbtUGswmYI Bljw== X-Gm-Message-State: AOAM532ZAXaOU731glh3R4b6PSn2V39WH1lnzikRdxtDb6XzlKYmaGpG jI+iZev4wGrGuCJ5V2YTlFN14WD3J7P3eA== X-Google-Smtp-Source: ABdhPJyuNO5bjp6RPnfTNrD8daqAF8IB2Q6QuImzZs20/aM7ghGmIw/zAmGaOvZGAb/wCHECkyLr9A== X-Received: by 2002:a62:5b05:0:b029:197:fafb:50f3 with SMTP id p5-20020a625b050000b0290197fafb50f3mr6256988pfb.76.1607129086627; Fri, 04 Dec 2020 16:44:46 -0800 (PST) Received: from mike-mac.lan (107-182-42-33.volcanocom.com. [107.182.42.33]) by smtp.gmail.com with ESMTPSA id g14sm5999773pfo.198.2020.12.04.16.44.45 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 04 Dec 2020 16:44:45 -0800 (PST) To: Brandon Long Cc: "John R. Levine" , "dmarc@ietf.org" References: <20201124020453.AFDC027CE5C8@ary.qy> <1eed8278-4efa-4abc-15e0-2efcf014e82e@mtcc.com> <446d491b-100a-9813-6463-2294f67bbda7@mtcc.com> <4190de2d-9f17-06d5-6354-30c989eecd4a@mtcc.com> <17d886fd-49fd-28d8-f8e4-7caf2e85919c@taugh.com> <8bc3c7ad-2a42-3eed-524c-8c50b16131c2@mtcc.com> <42178950-1ac3-27b4-a981-155fd9117969@taugh.com> <70bd5e9-f0e8-3bdf-c5f0-6428841e1577@iecc.com> <162586f5-d565-0e4f-955d-8ceca1d569d2@mtcc.com> From: Michael Thomas Message-ID: <40732425-0814-9e9a-2b7d-7adb304e9cdb@mtcc.com> Date: Fri, 4 Dec 2020 16:44:44 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------8443E68D44ACE96A74DDD241" Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] ARC questions X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 05 Dec 2020 00:44:50 -0000 This is a multi-part message in MIME format. --------------8443E68D44ACE96A74DDD241 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 12/4/20 3:27 PM, Brandon Long wrote: > I'm pretty sure I explained what the X-Google-DKIM-Signature was in > this or related threads.  It was > part of the original attempt at ARC, which was > X-Original-Authentication-Results.  Adding just > an XOAR header was not sufficient, we had to have reason to trust it, > so we added the signature. > We didn't re-use the existing DKIM-Signature header name because that > header was already used > by DMARC and had a bunch of other uses that we didn't want to use. DKIM doesn't have to be from the originating domain, and if you look at my mail headers in this message, you will see there is no originating domain signature because I changed over to gsuite last year. DMARC would just ignore all of those non-From domain signatures. I don't see the problem here. I don't understand what you mean about "trust". I thought the entire point of ARC was to deliver the intermediary's auth-res for consideration to the next hop(s). that could be done with XOAR and DKIM. If you don't agree, I would appreciate a step-by-step why that is not the case because I'm just not seeing it. And if X-Google is legacy, why is it still in your email headers? I have to say that when I came upon all of this it was definitely a wtf moment. I imagine that other people less familiar will look at it and have a FOMO moment. > So yes, that's a way to work around some of the issues if we wanted to > pursue the DKIM+A-R, > just have everyone sign with a different domain that you don't use for > mail.  That seems heavier > weight to me, but that would be a single-hop solution.  I think we did > discuss this in the early meetings > and found the ARC proposal provided more (multi-hop) and less > complicated (no new domains).  There's > also a phishing design challenge when picking a domain to represent > you in a limited way. The original intent was for mailing lists to always DKIM-resign with the domain of the mailing list. I expect that that happens today (and if they don't, ARC is not likely to be adopted either). So that can't possibly be heavier than adding two new signatures on top of that, since mailing lists would still have to apply the resigned DKIM signature. Mike > > Brandon > > On Wed, Dec 2, 2020 at 6:58 PM Michael Thomas > wrote: > > if you're trying to make a point about the bloat, you might > actually get > your facts straight. ARC adds an additional DKIM signature and a > Seal. i > have no idea what a X-Google-DKIM-Signature is and is not relevant. > > Mike > > On 12/2/20 6:55 PM, John R. Levine wrote: > >> PS: you're adding X-Google-DKIM-Signature which nobody knows > what its > >> utility is to your bloat total for dramatic effect. > > > > Um, it was there when your message arrived here. Complain to your > > mail provider. > > > >> On 12/2/20 6:33 PM, John R Levine wrote: > >>> On Wed, 2 Dec 2020, Michael Thomas wrote: > >>>>> But why bother?  The IANA header field registry currently > has 419 > >>>>> entries. Why is it a crisis if it increases to 422 rather > than 420? > >>>> > >>>> It does a lot more than that: > >>> > >>> We've been through this all before and none of these are > >>> persuasive.  For > >>> example: > >>> > >>>> 3) It adds a lot more bloat to the headers > >>> > >>> The message you just sent arrived with 4600 bytes of header (see > >>> below) and under 2K of text.  Copies that went through the dmarc > >>> mailing list probably had at least another 1K of header. > >>> > >>> If header bloat were ever an issue, it hasn't been for decades. > >>> > >>> R's, > >>> John > >>> ---- snip --- > >>> Return-Path: > > >>> X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on > gal.iecc.com > >>> X-Spam-Level: X-Spam-Status: No, score=-1.5 required=4.4 > >>> tests=BAYES_00,DCC_REPUT_00_12, > >>>     DKIM_SIGNED,DKIM_VALID,NICE_REPLY_A,RDNS_NONE,SPF_HELO_NONE > >>>     autolearn=no autolearn_force=no version=3.4.4 > >>> Delivered-To: johnl@iecc.com > >>> Received: (qmail 70731 invoked by uid 1014); 2 Dec 2020 > 23:30:07 -0000 > >>> Delivered-To: virtual-taugh-johnl@taugh.com > > >>> Received: (qmail 70729 invoked from network); 2 Dec 2020 > 23:30:07 -0000 > >>> Authentication-Results: iecc.com ; spf=pass > >>> spf.mailfrom=mike@fresheez.com > spf.helo=mail-pl1-x62a.google.com > >>> smtp.remote-ip="2607:f8b0:4864:20::62a"; dkim=pass > >>> header.d=mtcc-com.20150623.gappssmtp.com > header.s=20150623 > >>> header.a=rsa-sha256 header.b="vvoZ+Loe" > >>> Received: from mail-pl1-x62a.google.com > ([IPV6:2607:f8b0:4864:20::62a]) > >>>   by mail1.iecc.com > ([IPV6:2001:470:1f07:1126:33:5370:616d:6d31]) > >>>   with ESMTPS via TCP6 (port 38853/25) id 665297367 > >>>   tls TLS1.3_ECDHE_RSA_AES_128_GCM_AEAD sni mx1.taugh.com > ; 02 Dec > >>> 2020 23:30:06 -0000 > >>> Received: by mail-pl1-x62a.google.com > with SMTP id 4so91499plk.5 > >>>         for >; Wed, > 02 Dec 2020 15:30:05 -0800 (PST) > >>> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; > >>>         d=mtcc-com.20150623.gappssmtp.com > ; s=20150623; > >>> h=subject:to:cc:references:from:message-id:date:user-agent > >>> > :mime-version:in-reply-to:content-transfer-encoding:content-language; > >>> bh=frJndGBg4PljdPRXFB1KqYuhqqDFqbuyeJjhznmBtNo=; > >>> > b=vvoZ+Loew2ueICysZfzHi5UwJ3jXLN5dX+kyHN3HI91ZMJWMq7cym6dw1XQ9zaHvar > >>> > KWobHhYgPlIURrzw5+sM1lArZM0+S8zElTI9oJicfts5VpsuYtc3kGzpFO58DlGQMzji > >>> > +Bshah0JzXltImvCLjzUhHXHOLYvfA/Hk9lwY5XD904cTcBo4UfTKvenfFv3yLyBc4k3 > >>> > l61UDIWK7HRcdixAnDYx7zJLZaO3qcbPOwkG48uqCoMDIJVhcBndL82W/JflTPy4EB9S > >>> > VydV+ABOODKddInyT2i5+/cTXS1B66NWYHF/Auh1UqRkxB/+H5T//oXYkKWqXolceqkS > >>>          Y3Nw== > >>> 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=frJndGBg4PljdPRXFB1KqYuhqqDFqbuyeJjhznmBtNo=; > >>> > b=EiCvgdUtIHSRQXtcFgoSdo/YgcWiu1mxFOdlQ/tDw8nd2ipjfcUBNlRSW9ygClV9vu > >>> > TBZpT6xrU/F0xLA6fq9Tt51Z4S1VSgDSOCt1Ut8+oLzyBXkDCjQ3j8rByKqPkRvivOap > >>> > 82rO+tMd5J/4SMAAPGmJ28WAq+E7J4EJknvVu1LUOEiTERnAbmT9ZK/eTEKPjQGx0msa > >>> > GMCKzawKzSfLMvOIqaKoPUmxPyrtEnEUizEPer7/aXZ0pXrUTHQ82984GTYqSdKDoYIS > >>> > T+59dBxbPY9KwT33oih+1slVUSLBEbzUigK3wj4yA/71KTvr76KCUEaU8cYI6/TYcszz > >>>          2CWA== > >>> X-Gm-Message-State: > >>> AOAM530XUwEgBdQ2e02rPshm7iyXROuyhTJeAndRJAFtQO8oX1JUEgsD > >>>     chdQCnyR1XB3fAEw5oIqGysS4Q== > >>> X-Google-Smtp-Source: > >>> > ABdhPJzQUtiWyUp4dVxdii6hT+h4YBukyVaoJ5846n5Di6IUaEwxKrufF/3Atxm7lejww+dr4k5xIw== > >>> X-Received: by 2002:a17:90a:c4f:: with SMTP id > >>> u15mr287214pje.177.1606951804840; > >>>         Wed, 02 Dec 2020 15:30:04 -0800 (PST) > >>> Return-Path: > > >>> Received: from mike-mac.lan (107-182-42-33.volcanocom.com > . > >>> [107.182.42.33]) > >>>         by smtp.gmail.com with ESMTPSA id > >>> x7sm158495pfn.85.2020.12.02.15.30.03 > >>>         (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 > bits=128/128); > >>>         Wed, 02 Dec 2020 15:30:04 -0800 (PST) > >>> Subject: Re: [dmarc-ietf] ARC questions > >>> To: John R Levine >, > Brandon Long > > >>> Cc: IETF DMARC WG > > >>> References: <20201124020453.AFDC027CE5C8@ary.qy> > >>>   > > >>> >   > > >>>   > > >>> >   > > >>>  <1eed8278-4efa-4abc-15e0-2efcf014e82e@mtcc.com > > > >>> >   > > >>>  <446d491b-100a-9813-6463-2294f67bbda7@mtcc.com > > > >>>   > > >>>  <4190de2d-9f17-06d5-6354-30c989eecd4a@mtcc.com > > > >>>  <17d886fd-49fd-28d8-f8e4-7caf2e85919c@taugh.com > > > >>>   > > >>>   > > >>> From: Michael Thomas > > >>> Message-ID: <8bc3c7ad-2a42-3eed-524c-8c50b16131c2@mtcc.com > > > >>> Date: Wed, 2 Dec 2020 15:30:01 -0800 > >>> User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) > >>>  Gecko/20100101 Thunderbird/78.5.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 > >> > >> > > > > Regards, > > John Levine, johnl@taugh.com , Primary > Perpetrator of "The Internet for > > Dummies", > > Please consider the environment before reading this e-mail. > https://jl.ly > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > > --------------8443E68D44ACE96A74DDD241 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit


On 12/4/20 3:27 PM, Brandon Long wrote:
I'm pretty sure I explained what the X-Google-DKIM-Signature was in this or related threads.  It was
part of the original attempt at ARC, which was X-Original-Authentication-Results.  Adding just
an XOAR header was not sufficient, we had to have reason to trust it, so we added the signature.
We didn't re-use the existing DKIM-Signature header name because that header was already used
by DMARC and had a bunch of other uses that we didn't want to use.

DKIM doesn't have to be from the originating domain, and if you look at my mail headers in this message, you will see there is no originating domain signature because I changed over to gsuite last year. DMARC would just ignore all of those non-From domain signatures. I don't see the problem here.

I don't understand what you mean about "trust". I thought the entire point of ARC was to deliver the intermediary's auth-res for consideration to the next hop(s). that could be done with XOAR and DKIM. If you don't agree, I would appreciate a step-by-step why that is not the case because I'm just not seeing it.

And if X-Google is legacy, why is it still in your email headers? I have to say that when I came upon all of this it was definitely a wtf moment. I imagine that other people less familiar will look at it and have a FOMO moment.


So yes, that's a way to work around some of the issues if we wanted to pursue the DKIM+A-R,
just have everyone sign with a different domain that you don't use for mail.  That seems heavier
weight to me, but that would be a single-hop solution.  I think we did discuss this in the early meetings
and found the ARC proposal provided more (multi-hop) and less complicated (no new domains).  There's
also a phishing design challenge when picking a domain to represent you in a limited way.

The original intent was for mailing lists to always DKIM-resign with the domain of the mailing list. I expect that that happens today (and if they don't, ARC is not likely to be adopted either). So that can't possibly be heavier than adding two new signatures on top of that, since mailing lists would still have to apply the resigned DKIM signature.

Mike



Brandon

On Wed, Dec 2, 2020 at 6:58 PM Michael Thomas <mike@mtcc.com> wrote:
if you're trying to make a point about the bloat, you might actually get
your facts straight. ARC adds an additional DKIM signature and a Seal. i
have no idea what a X-Google-DKIM-Signature is and is not relevant.

Mike

On 12/2/20 6:55 PM, John R. Levine wrote:
>> PS: you're adding X-Google-DKIM-Signature which nobody knows what its
>> utility is to your bloat total for dramatic effect.
>
> Um, it was there when your message arrived here.  Complain to your
> mail provider.
>
>> On 12/2/20 6:33 PM, John R Levine wrote:
>>> On Wed, 2 Dec 2020, Michael Thomas wrote:
>>>>> But why bother?  The IANA header field registry currently has 419
>>>>> entries. Why is it a crisis if it increases to 422 rather than 420?
>>>>
>>>> It does a lot more than that:
>>>
>>> We've been through this all before and none of these are
>>> persuasive.  For
>>> example:
>>>
>>>> 3) It adds a lot more bloat to the headers
>>>
>>> The message you just sent arrived with 4600 bytes of header (see
>>> below) and under 2K of text.  Copies that went through the dmarc
>>> mailing list probably had at least another 1K of header.
>>>
>>> If header bloat were ever an issue, it hasn't been for decades.
>>>
>>> R's,
>>> John
>>> ---- snip ---
>>> Return-Path: <mike@fresheez.com>
>>> X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on gal.iecc.com
>>> X-Spam-Level: X-Spam-Status: No, score=-1.5 required=4.4
>>> tests=BAYES_00,DCC_REPUT_00_12,
>>>     DKIM_SIGNED,DKIM_VALID,NICE_REPLY_A,RDNS_NONE,SPF_HELO_NONE
>>>     autolearn=no autolearn_force=no version=3.4.4
>>> Delivered-To: johnl@iecc.com
>>> Received: (qmail 70731 invoked by uid 1014); 2 Dec 2020 23:30:07 -0000
>>> Delivered-To: virtual-taugh-johnl@taugh.com
>>> Received: (qmail 70729 invoked from network); 2 Dec 2020 23:30:07 -0000
>>> Authentication-Results: iecc.com; spf=pass
>>> spf.mailfrom=mike@fresheez.com spf.helo=mail-pl1-x62a.google.com
>>> smtp.remote-ip="2607:f8b0:4864:20::62a"; dkim=pass
>>> header.d=mtcc-com.20150623.gappssmtp.com header.s=20150623
>>> header.a=rsa-sha256 header.b="vvoZ+Loe"
>>> Received: from mail-pl1-x62a.google.com ([IPV6:2607:f8b0:4864:20::62a])
>>>   by mail1.iecc.com ([IPV6:2001:470:1f07:1126:33:5370:616d:6d31])
>>>   with ESMTPS via TCP6 (port 38853/25) id 665297367
>>>   tls TLS1.3_ECDHE_RSA_AES_128_GCM_AEAD sni mx1.taugh.com; 02 Dec
>>> 2020 23:30:06 -0000
>>> Received: by mail-pl1-x62a.google.com with SMTP id 4so91499plk.5
>>>         for <johnl@taugh.com>; Wed, 02 Dec 2020 15:30:05 -0800 (PST)
>>> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
>>>         d=mtcc-com.20150623.gappssmtp.com; s=20150623;
>>> h=subject:to:cc:references:from:message-id:date:user-agent
>>> :mime-version:in-reply-to:content-transfer-encoding:content-language;
>>>         bh=frJndGBg4PljdPRXFB1KqYuhqqDFqbuyeJjhznmBtNo=;
>>> b=vvoZ+Loew2ueICysZfzHi5UwJ3jXLN5dX+kyHN3HI91ZMJWMq7cym6dw1XQ9zaHvar
>>> KWobHhYgPlIURrzw5+sM1lArZM0+S8zElTI9oJicfts5VpsuYtc3kGzpFO58DlGQMzji
>>> +Bshah0JzXltImvCLjzUhHXHOLYvfA/Hk9lwY5XD904cTcBo4UfTKvenfFv3yLyBc4k3
>>> l61UDIWK7HRcdixAnDYx7zJLZaO3qcbPOwkG48uqCoMDIJVhcBndL82W/JflTPy4EB9S
>>> VydV+ABOODKddInyT2i5+/cTXS1B66NWYHF/Auh1UqRkxB/+H5T//oXYkKWqXolceqkS
>>>          Y3Nw==
>>> 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=frJndGBg4PljdPRXFB1KqYuhqqDFqbuyeJjhznmBtNo=;
>>> b=EiCvgdUtIHSRQXtcFgoSdo/YgcWiu1mxFOdlQ/tDw8nd2ipjfcUBNlRSW9ygClV9vu
>>> TBZpT6xrU/F0xLA6fq9Tt51Z4S1VSgDSOCt1Ut8+oLzyBXkDCjQ3j8rByKqPkRvivOap
>>> 82rO+tMd5J/4SMAAPGmJ28WAq+E7J4EJknvVu1LUOEiTERnAbmT9ZK/eTEKPjQGx0msa
>>> GMCKzawKzSfLMvOIqaKoPUmxPyrtEnEUizEPer7/aXZ0pXrUTHQ82984GTYqSdKDoYIS
>>> T+59dBxbPY9KwT33oih+1slVUSLBEbzUigK3wj4yA/71KTvr76KCUEaU8cYI6/TYcszz
>>>          2CWA==
>>> X-Gm-Message-State:
>>> AOAM530XUwEgBdQ2e02rPshm7iyXROuyhTJeAndRJAFtQO8oX1JUEgsD
>>>     chdQCnyR1XB3fAEw5oIqGysS4Q==
>>> X-Google-Smtp-Source:
>>> ABdhPJzQUtiWyUp4dVxdii6hT+h4YBukyVaoJ5846n5Di6IUaEwxKrufF/3Atxm7lejww+dr4k5xIw==
>>> X-Received: by 2002:a17:90a:c4f:: with SMTP id
>>> u15mr287214pje.177.1606951804840;
>>>         Wed, 02 Dec 2020 15:30:04 -0800 (PST)
>>> Return-Path: <mike@fresheez.com>
>>> Received: from mike-mac.lan (107-182-42-33.volcanocom.com.
>>> [107.182.42.33])
>>>         by smtp.gmail.com with ESMTPSA id
>>> x7sm158495pfn.85.2020.12.02.15.30.03
>>>         (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
>>>         Wed, 02 Dec 2020 15:30:04 -0800 (PST)
>>> Subject: Re: [dmarc-ietf] ARC questions
>>> To: John R Levine <johnl@taugh.com>, Brandon Long <blong@google.com>
>>> Cc: IETF DMARC WG <dmarc@ietf.org>
>>> References: <20201124020453.AFDC027CE5C8@ary.qy>
>>>  <cd855b53-d9bd-3412-3bd5-dc4b7720dc5c@mtcc.com>
>>>  <CABa8R6s0bfs87Fu9eOq_R3WH1pngauVXrw3RSPe9iWWCtf3AmQ@mail.gmail.com>
>>>  <c954eadd-5c85-c0d9-2168-8a42de506b72@mtcc.com>
>>>  <CABa8R6swzAQLPU=xE2tr1W0J5r+w80BSYu87_ubMwHaUMgmKvA@mail.gmail.com>
>>>  <1eed8278-4efa-4abc-15e0-2efcf014e82e@mtcc.com>
>>>  <CABa8R6sEk+dHwHjBCKDgcmeT_Z3FymC5+jzy-GGa=7gJYvOf5A@mail.gmail.com>
>>>  <446d491b-100a-9813-6463-2294f67bbda7@mtcc.com>
>>>  <aafa5e78-aff9-8076-b76f-62f5b3a13fc1@taugh.com>
>>>  <4190de2d-9f17-06d5-6354-30c989eecd4a@mtcc.com>
>>>  <17d886fd-49fd-28d8-f8e4-7caf2e85919c@taugh.com>
>>>  <f785884b-2a3d-a6fe-6bb6-ee792d23ff23@mtcc.com>
>>>  <d5e9dbe-7d83-d3b1-2aa9-3e3562d3e75@taugh.com>
>>> From: Michael Thomas <mike@mtcc.com>
>>> Message-ID: <8bc3c7ad-2a42-3eed-524c-8c50b16131c2@mtcc.com>
>>> Date: Wed, 2 Dec 2020 15:30:01 -0800
>>> User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0)
>>>  Gecko/20100101 Thunderbird/78.5.0
>>> MIME-Version: 1.0
>>> In-Reply-To: <d5e9dbe-7d83-d3b1-2aa9-3e3562d3e75@taugh.com>
>>> Content-Type: text/plain; charset=utf-8; format=flowed
>>> Content-Transfer-Encoding: 8bit
>>> Content-Language: en-US
>>
>>
>
> Regards,
> John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for
> Dummies",
> Please consider the environment before reading this e-mail. https://jl.ly

_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
--------------8443E68D44ACE96A74DDD241-- From nobody Fri Dec 4 19:58: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 7DA683A0962 for ; Fri, 4 Dec 2020 19:58:43 -0800 (PST) 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 TfyBzj7rYBRW for ; Fri, 4 Dec 2020 19:58:41 -0800 (PST) Received: from mail-vk1-xa33.google.com (mail-vk1-xa33.google.com [IPv6:2607:f8b0:4864:20::a33]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B91683A095F for ; Fri, 4 Dec 2020 19:58:41 -0800 (PST) Received: by mail-vk1-xa33.google.com with SMTP id v185so1769888vkf.8 for ; Fri, 04 Dec 2020 19:58:41 -0800 (PST) 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=965ONkz/m8iGzCXrj4yfegq/N+72AkAX92ukM8F/sfo=; b=M2ngiWnn03CehFyOER5By9d+ZPdEIIx/wjMhNTNplJC9w96ZySYhcv3bbVo1LHMaNc FvbUxjuQTGVcBce+OjRQmYWxNuqNY8q1cPUhibqgAtur2byrRFJo3MQfZNoXMwkcorc9 SrbcT9GzErlcvOkXw9yfwYZQ4Yg9dLpr85TUj80So34AhFrI8utB+g9T6QH3S9tayTQ1 kOOutLbtQ1Aa7QT8G7PiH5bZUb5iPYLQgyUQ2Je1gZBI57S2FwxIWR8y85piLVavKSrx O0PUM1nWNrsZPgsvkIudZdzysQmz0NquidUnCVVOAUiyK97IOY6g/o3RHI90VJKkzmGa qAEQ== 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=965ONkz/m8iGzCXrj4yfegq/N+72AkAX92ukM8F/sfo=; b=CqJ+NiNR5h8hsqm0+r07PhGyS/Hl79Oe3hOOESm2gZ0CuUhVOW5erpzgvHtrlWVBIF R9x++lde4z7SRQbT1pgP/AG5SUgRmLBt7XyFTNSVh62jDvy0oJgJpH+GGfThfgyN7VOI P3oLpEnWBs/a4OpQNbuIpC98T2tyWT0SoFQdaWNXvag0EooWOESd+CT43owRJrFt5b3Y ebPYzOLKSQbYPDyfr/Cb/hlhHnUFM/5SdrMKKlROl1kplm32JBpav9g7l6MFS5/WZk2l 3SEjt3sLl+mL3AWRJTdPweq+OKm3qy69DzFdQlLfpC5IrIXR1/bf++rLnDDBDFLFTy7j p5Og== X-Gm-Message-State: AOAM531bO/M2oK0Nv2KT6OJ26KCEKtcoAzG4rTFWGOzDvfH9e65njHdu SGmAtOuxwVwUadtNbh9774hV4pm/pNbmHye+Eu8h/upiyJE= X-Google-Smtp-Source: ABdhPJxGb74atHFBG/+aCiKoJg5JY3XVLu1peSqM+tjVj4Ks0+ENBNC2ZOt1grt46dKeTCAL1snhdawbGPOzaohHHVk= X-Received: by 2002:a1f:9f04:: with SMTP id i4mr7486366vke.7.1607140720522; Fri, 04 Dec 2020 19:58:40 -0800 (PST) MIME-Version: 1.0 From: Douglas Foster Date: Fri, 4 Dec 2020 22:58:30 -0500 Message-ID: To: dmarc@ietf.org Content-Type: multipart/alternative; boundary="000000000000c03c6805b5af9b59" Archived-At: Subject: [dmarc-ietf] DMARC and ARC X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 05 Dec 2020 03:58:44 -0000 --000000000000c03c6805b5af9b59 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Michael Thomas has asked some questions which have stimulated my thinking about how to describe the big-picture questions here. I suggest that too much attention has been focused on solving the =E2=80=9C= mailing list=E2=80=9D problem, and too little on the =E2=80=9Cmessage receiver=E2= =80=9D problem. Forwarded email creates big problems for message receivers. First, lets begin with the obvious: malicious messages come from enterprises that are in the malicious message business. They rarely send just one message, and their content changes continually. Therefore, my priority is to block malicious sources. Messages that are correctly blocked on content, rather than source, are the canary-in-the-mine which warns me that my sender blocks need to be tightened. I currently use 5 identifiers to apply a reputation, and therefore a disposition, to a message source: Source IP, HELO name, ReverseDNS name, SMTP Address, and From Address. These identifiers are combined with the available verification methods: Forward-confirming the two DNS names to the source IP, SPF PASS, and DMARC-compliant. On any specific message, some of this information is not required to assign a reputation and disposition, but across a day=E2=80=99s messages, each of these identifiers= and attributes are needed at some point. If a message is not forwarded, every organization involved in its delivery is assumed to have a relationship to the sender and therefore a shared responsibility for the final product. DMARC, SPF, and many spam filters assume that the adjacent MTA is the only source that needs to be evaluated. Forwarding introduces an intermediary organization which presumably operates on behalf of the recipient, rather than the sender. It is not involved in the creation of the message and has no economic relationship with most of the message sources. More importantly, because it will be forwarding messages from sources with a variety of reputations, the forwarder will be perceived as having a very unreliable reputation =E2=80= =93 sending both very much unwanted content and very much wanted content from the same or overlapping identifiers. SPF and DMARC force the forwarder to reliably identify itself, but in this process, they force the forwarder to hide information that the receiving MTA needs for proper message filtering. This aggravates any effort to filter based on original-source identity. Consequently, both the recipient MTA and the forwarding MTA need for the recipient MTA to evaluate a message based on the true source, the entity (or entities) prior to the forwarder. Unfortunately, we have no reliable way to know if a message has been forwarded, although some guessing strategies are available. Even when forwarding is presumed, reconstructing the 5-identifier / 4 verification dataset is nearly impossible due to data loss. Any attempt to evaluate prior sources requires evaluating the entire Received chain, and the supporting data, including ARC, which goes with it. ARC begins to give us a way to trust parts of the Received chain, and this moves us toward the possibility of evaluating the Received chain effectively. But it does not meet my needs, because it does not ensure that I can use any specific ARC Set to reconstruct the 5 identifier / 4 verifications dataset needed to evaluate the source correctly. Additionally, evaluating the Received chain is a huge increase in complexity, for both the code to implement an algorithm and the run-time processing needed to execute the algorithm. Processing power and coding sophistication keeps getting better, so perhaps the main problem is getting the data set right. --000000000000c03c6805b5af9b59 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Michael Thomas has= asked some questions which have stimulated my thinking about how to describe the big-picture questions here= .

I suggest that too much attention h= as been focused on solving the =E2=80=9Cmailing list=E2=80=9D problem, and too little on the =E2=80=9Cmessage receiver=E2=80=9D problem.= =C2=A0=C2=A0=C2=A0 Forwarded email creates big problems for message receivers.

First, lets begin with the obvious:= =C2=A0=C2=A0 malicious messages come from enterprises that are in the malicious message business.=C2=A0=C2=A0 They rarely send just one message, and their content changes continually.= =C2=A0=C2=A0 Therefore, my priority is to block malicious sources.=C2=A0=C2=A0 Messages that are correctly blocked on content, rather than source, are the canary-in-the-mine which wa= rns me that my sender blocks need to be tightened.

I currently use 5 identifiers to ap= ply a reputation, and therefore a disposition, to a message source:=C2=A0=C2=A0=C2=A0 Source IP, HELO name, ReverseDNS name, SMTP Address, and From Address.=C2=A0=C2=A0 These identifiers are combined with the available verification methods:=C2=A0=C2=A0 Forward-confirming the two DNS names to the source IP, SPF PASS, and DMARC-compliant.=C2=A0=C2=A0=C2=A0 On any specific message, some of this information is not required to assign a reputation an= d disposition, but across a day=E2=80=99s messages, each of these identifiers= and attributes are needed at some point.

If a message is not forwarded, ever= y organization involved in its delivery is assumed to have a relationship to the sender and therefore = a shared responsibility for the final product.=C2=A0=C2=A0 DMARC, SPF, and many spam filters assume that the adjacent MTA is the only source that needs to be evaluated.

Forwarding introduces an intermedia= ry organization which presumably operates on behalf of the recipient, rather than the sender.=C2=A0=C2=A0 It= is not involved in the creation of the message and has no economic relationship with most of the message sources.=C2=A0=C2=A0 More importantly, because it will be forwarding messages from sources with a variety of reput= ations, the forwarder will be perceived as having a very unreliable reputation =E2= =80=93 sending both very much unwanted content and very much wanted content from t= he same or overlapping identifiers.=C2=A0=C2=A0 SPF and DMARC force the forwarder to reliably identify itself, but in this process, they force the forwarder to hide information that the receiving MTA needs f= or proper message filtering.=C2=A0 This aggravates any effort to filter based = on original-source identity.

Consequently, both the recipient MT= A and the forwarding MTA need for the recipient MTA to evaluate a message based on the true source, the entity (or entities) prior to the forwarder.=C2=A0=C2=A0 Unfort= unately, we have no reliable way to know if a message has been forwarded, although some guessing strategies are avai= lable.=C2=A0=C2=A0 Even when forwarding is presumed, reconstructing the 5-identifier / 4 verification dataset is nearly impossible due to data = loss.

Any attempt to evaluate prior sources requires evaluating the entire Received chain, and the supporting data, including ARC, which go= es with it.=C2=A0=C2=A0=C2=A0 = ARC begins to give us a way to trust parts of the Received chain, and this moves us toward the possibility of evaluati= ng the Received chain effectively.=C2=A0=C2= =A0 But it does not meet my needs, because it does not ensure that I can use any specific ARC Set to reconstruct the 5 identifier / 4 verifications dataset needed to evaluate t= he source correctly.=C2=A0=C2=A0<= /p>

A= dditionally, evaluating the Received chain is a huge increase in complexity, for both the code to implement an a= lgorithm and the run-time processing needed to execute the algorithm.=C2=A0=C2=A0=C2=A0 Processing power and coding sophistication keeps getting better, so perhaps the main problem is getting the data set r= ight.

=C2=A0

=C2=A0

--000000000000c03c6805b5af9b59-- From nobody Sat Dec 5 04:13: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 B43743A07B3 for ; Sat, 5 Dec 2020 04:13:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.12 X-Spam-Level: X-Spam-Status: No, score=-2.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, 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 3Z1-OF2Giqap for ; Sat, 5 Dec 2020 04:13:21 -0800 (PST) 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 CC8AE3A07AE for ; Sat, 5 Dec 2020 04:13:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1607170397; bh=7DfryTO1Cr3Nd8BQOltBN0SNreLVggIqDASxXwKsqrE=; l=1074; h=To:References:From:Date:In-Reply-To; b=BH7qHuK8OzilOmB6/iG3HSIxq10YiUcorzHXV1uYpAhfal+dKWe9vpYRGxjmOlAZ4 I29vs5OS1QygriCZ50jvSYu1k9CE6u0XMZlITsHBJ1jGemhxedl3xkOLsPQ6aAfaMt NGz7kAiMKqmpBJlMVfWqhAnb+xRFi7YxTKhUjYZzwn0PnQnBkolBR+J3nypDJ Authentication-Results: tana.it; auth=pass (details omitted) Original-From: Alessandro Vesely 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.000000005FCB795D.0000043B; Sat, 05 Dec 2020 13:13:17 +0100 To: John R Levine , dmarc@ietf.org References: <20201202233432.D45FB28E1943@ary.qy> <479cfb50-b98e-fbbe-e7ce-375557cd624@taugh.com> <0a650f5d-c53d-ab45-4125-6491c413f70b@tana.it> From: Alessandro Vesely Message-ID: Date: Sat, 5 Dec 2020 13:13:17 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] Ticket #42 - Expand DMARC reporting URI functionality X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 05 Dec 2020 12:13:23 -0000 On Fri 04/Dec/2020 19:21:33 +0100 John R Levine wrote: >>> I meant "at the same time" as in during the same reporting run.  As Dave >>> noted, if you sent any particular report by https, there's no need to send >>> it again by mail. >> >> Got it.  However, the spec says it's a list of addresses to which aggregate >> feedback is to be sent.  When there are multiple entries, up to now, reports >> are sent to each. > > Hm, we might want to revisit that.  If a domain wants mail sent to three > places, it's not like it's hard to arrange for forwarding.  My intention is > that if you send the report by https, you're done. The VALCHAR element in Section 3.2 of RFC 6376 accepts "/", which is seldom used in email addresses and ubiquitous in https URIs. We could convene that when a mailto is to be considered as an alternative to an https, then the former should precede the latter, separated by a slash. For example: v=DMARC1; p=none; rua=mailto:local@example.com, mailto:report@service.example/https://service.example/report/; Best Ale -- From nobody Sat Dec 5 05:21: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 2DFEF3A0B08 for ; Sat, 5 Dec 2020 05:21:01 -0800 (PST) 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 B6cGR2JN3p87 for ; Sat, 5 Dec 2020 05:20:59 -0800 (PST) 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 154913A0B05 for ; Sat, 5 Dec 2020 05:20:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1607174455; bh=FJJ9m2RB8fy7AqgnXKA8alc0llUYo36nKoxWeFhAeHY=; l=5668; h=To:Cc:References:From:Date:In-Reply-To; b=CJDhFSX1RrK6J8g3Z7UXmS35DnaeM9KtQvz936aqu+SxN6l4Te5hzMPi+t89QuH9r fgwgHdpfr4C5KFUlc8rrEp/42FEFhhNKXJ2eilNX8MsQFwfhgAU673enhLVxKNkpWU FTLdQLx1Inqk0HEH2ZIdOajcYb6Bm3/uI6MCQbOhHnrFjHQX6EI/PIEw9fsrA Authentication-Results: tana.it; auth=pass (details omitted) Original-From: Alessandro Vesely Original-Cc: IETF DMARC WG 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.000000005FCB8937.00000ACB; Sat, 05 Dec 2020 14:20:55 +0100 To: Brandon Long Cc: IETF DMARC WG References: <8c83fffc-077d-9ddb-db2f-b9763361c60f@tana.it> <39eafc5e-3d9c-0bea-1173-7277070195ea@wisc.edu> <081c42a3-492b-89b7-ad76-ccec48dea091@tana.it> <2d1dca4f-e46a-646c-9fa3-d9ca56c72196@tana.it> <01d1849f-6a0a-5307-db54-7587e33fc018@tana.it> From: Alessandro Vesely Message-ID: Date: Sat, 5 Dec 2020 14:20:55 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] A policy for direct mail flows only, was ARC questions X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 05 Dec 2020 13:21:01 -0000 On Fri 04/Dec/2020 23:45:47 +0100 Brandon Long wrote: > On Wed, Dec 2, 2020 at 3:11 AM Alessandro Vesely wrote: >> On Wed 02/Dec/2020 03:14:46 +0100 Brandon Long wrote: >>> On Tue, Dec 1, 2020 at 2:37 AM Alessandro Vesely wrote: >>>> On Tue 01/Dec/2020 05:56:46 +0100 Brandon Long wrote: >>>>> On Thu, Nov 26, 2020 at 12:59 AM Alessandro Vesely wrote: >>>>>> On 25/11/2020 20:16, Michael Thomas wrote: >>>>>>> On 11/25/20 11:11 AM, Alessandro Vesely wrote: >>>>>>>> On 25/11/2020 19:24, Jesse Thompson wrote: >>>>>>>>> On 11/25/20 11:30 AM, Alessandro Vesely wrote: >>>>>>>>>> Without resorting to ARC, it is still possible to validate >>>>>>>>>> author domain's signatures directly if the MLM just adds a >>>>>>>>>> subject tag and a footer >>>>>>>>> >>>>>>>>> I agree that ARC isn't really needed to do this (trust the >>>>>>>>> last hop from the MLM and determine the original >>>>>>>>> authenticity from the MLM's perspective) >>>>>>>> >>>>>>>> I didn't mean to trust the MLM. I meant remove the subject >>>>>>>> tag and the footer, then the original DKIM signature verifies. >>>>>>>> See: >>>>>>>> https://datatracker.ietf.org/doc/draft-vesely-dmarc-mlm-transform/ >>>>>>> >>>>>>> When I was at Cisco, with l= and some subject line heuristics I >>>>>>> could get probably like 90+% verification rate across the entire >>>>>>> company, a company that uses external mailing lists a lot. >>>>>>> Definitely not 100% though. >>>>>> >>>>>> DKIM itself is not 100%. You always have lines beginning with >>>>>> "From " or occasional autoconversions. >>>>>> >>>>>> l= doesn't cover multipart/alternative nor >>>>>> Content-Transfer-Encoding: base64. In addition, the DKIM spec >>>>>> discourages its usage and suggests that "Assessors might wish to >>>>>> ignore signatures that use the tag." >>>>> >>>>> Right, some of the other dkim-light or diff concepts we discussed >>>>> would be better than using l= >>>>> >>>>> We again got hung up on the 100% solution, though... something that >>>>> handled subject-prefix and footer in a transport agnostic way might >>>>> have worked. >>>> >>>> I'm not clear about the meaning of "100%". If an author domain puts >>>> no DKIM signatures, there is no way to verify them. Hence, some >>>> compliance of the author domain has to be required. >>>> >>>> The same holds for conditional signatures. >>>> >>>> The same holds for MLM transformations. >>> >>> Yes, by 100% I meant of messages that were already authenticated and >>> therefore should continue to be authenticated through the relay. >> >> That's ARC. If a message lacks DKIM and was SPF-authenticated, there's >> no way it can continue to be authenticated through a relay. >> >> OTOH, mailing lists and relays are two different beasts. For one thing, >> it is very unusual for a mailing list to send to another mailing list. >> Thus, we can safely specify a non-stackable authentication method. > > mailing list to mailing list mail is very common in GSuite, but maybe we're > a special case. Part of that was that aliases were moved to the mailing > list infra (which is definitely more of an "our problem" than everyone), but > we also see common usage where companies make groups matching their > hierarchy (the all company group goes to all department groups which go to > all local groups etc). We also see some where announce groups mix contrib > groups, etc. Especially since we also use the same groups as ACL groups for > GSuite and Google Cloud, so hierarchical groups are very common. I'm not familiar with that feature. How does a list get subscribed to another list? In general, a list accepts messages from subscribed users, so if dmarc-ietf distributed this message to another list which I'm not a subscriber of, it would not pass. (From: rewriting changes that behavior. For example, one could subscribe to a list which routinely rewrites From: on behalf of this list, dmarc-ietf. If the former list traffic is very high, that subscribing could be a sort of DoS attack to us.) > (there was a recent common where someone said who needs an org chart when > we have email, showing the list of footers for all of the org level mailing > lists the message went to to get to them) The mlm-transform draft (referenced above) limits footers to 10 lines of text, each shorter than 80 characters. If the hierarchy is not deeper than 10, the chart can fit within a single footer. Note that every added line breaks all previous signatures. However, only the author domain's signature is worth being recovered, as far as MLM transformations are concerned. ARC can still certify the whole chain. The 10 lines limit is arbitrary. It is meant to avoid that recipients mistake the footer for the main part of the message. > (one construction of hierarchical announce lists that was not well > considered did result in every person on the combined list getting 9000 > copies of messages to the list, so flattening lists is sometimes much > preferred) > > Which isn't to say we couldn't work around it or do the work to flatten the > lists, though it increases the complexity of the product (can you > unsubscribe from the top level list but not a sub list?) I guess some coordination among sublists is required anyway. To recognize that a message arrives from a sublist, and hence mangle the existing footer instead of adding a new one, is certainly an added complexity. Maybe, the number of lists in such condition is low enough to let MLM transformation reversion still worth being deployed? Best Ale -- From nobody Sat Dec 5 05:52: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 0F3B23A0B9D for ; Sat, 5 Dec 2020 05:52:01 -0800 (PST) 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_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, SPOOF_COM2OTH=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N3d2Gx8iXmUL for ; Sat, 5 Dec 2020 05:51:59 -0800 (PST) Received: from mx0b-00143702.pphosted.com (mx0b-00143702.pphosted.com [148.163.141.77]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 271F93A0B9C for ; Sat, 5 Dec 2020 05:51:58 -0800 (PST) Received: from pps.filterd (m0156894.ppops.net [127.0.0.1]) by mx0b-00143702.pphosted.com (8.16.0.43/8.16.0.43) with SMTP id 0B5DmDo9028372 for ; Sat, 5 Dec 2020 08:51:57 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.com; h=from : to : subject : date : message-id : content-type : content-transfer-encoding : mime-version; s=20190412; bh=0NhTGjAjfAGWYM2m+6zh1k9RYZvG//Qmz2sx7+8QEtA=; b=WrKM+tWxrzyXc9aQYNnrY6+ZTr0c6sG9ypVcedJm0gOnxqh+wVr8qYaK8kOJoHW9CvVb OeEo95at9I9MGGkYdw4zrgaeEZejUK0jjnSCcN5LMMIYBVbKDQ95tEQ+hEt/WzUuuDIe E/KNzsPMscKLWQ8HWN80ejLa0bP9E0LjJGCyQ3nTDcY95a1Z/htfq1jo4MJVBy4i2Syf I5IkbnxI66TtmGsByVHVgxJG++ZY9JVj22zW8wBRRCWIkMgQNhPdiCtCNXQwvyJjr8+4 /fwdrfmGDiBUW3KzNZ/zsHdS3pwC2p2Yi9L5IIxA+PMfBA+R/+7LvwknMOVqmedBh+x/ LA== Received: from copdcexc39.cable.comcast.com (dlppfpt-po-1p.slb.comcast.com [96.99.226.137]) by mx0b-00143702.pphosted.com with ESMTP id 3587xw8pnn-4 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for ; Sat, 05 Dec 2020 08:51:57 -0500 Received: from copdcexc33.cable.comcast.com (147.191.125.132) by copdcexc39.cable.comcast.com (147.191.125.138) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1713.5; Sat, 5 Dec 2020 06:51:55 -0700 Received: from COPDCEXEDGE01.cable.comcast.com (96.114.158.213) by copdcexc33.cable.comcast.com (147.191.125.132) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1713.5 via Frontend Transport; Sat, 5 Dec 2020 06:51:55 -0700 Received: from NAM11-DM6-obe.outbound.protection.outlook.com (104.47.57.177) by webmail.comcast.com (96.114.158.213) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Sat, 5 Dec 2020 08:52:00 -0500 Received: from MN2PR11MB4351.namprd11.prod.outlook.com (2603:10b6:208:193::31) by MN2PR11MB4176.namprd11.prod.outlook.com (2603:10b6:208:13b::26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3632.17; Sat, 5 Dec 2020 13:51:52 +0000 Received: from MN2PR11MB4351.namprd11.prod.outlook.com ([fe80::7ca6:b482:a6b0:4d42]) by MN2PR11MB4351.namprd11.prod.outlook.com ([fe80::7ca6:b482:a6b0:4d42%7]) with mapi id 15.20.3632.021; Sat, 5 Dec 2020 13:51:52 +0000 From: "Brotman, Alex" To: "dmarc@ietf.org" Thread-Topic: Discussion: Removal of validation for external destinations (Ticket #76) Thread-Index: AdbLDJ36lgBe/Aa+SKaTRhc/gVa6SQ== Date: Sat, 5 Dec 2020 13:51:52 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=comcast.com; x-originating-ip: [2601:43:101:380:60ff:eff6:6cc1:16f5] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 31592723-0c94-4315-055d-08d89924eb8a x-ms-traffictypediagnostic: MN2PR11MB4176: 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: 23N08KYngz0xS1wY8TEXxA+OLjRCgSejn/NUeUk47MWxWFVpVgNKimcWK8jBfPm5FxVUx6SnL6TEbeZw+4vPBFAAh6XwqOVtAflkM7Z8TbMaVCVHxPpeuh4p4jLdwxMTZ5ctnnLs519DpfXUWmh4kT5tbOerrpogbHQAKVgyxoEIK41YcKYDjypfYGAVrm1n8crUOU3bRreUA52NmrwKPXwJ21NuYkG6ACkT11y1f7a2zX3nCOnUUCxvQq2Qi5XJ0q5+fKxpAMNU1AeNqiyb8B3KloouuxNlSvLJjHiCG9sPq+v6K0sPad8Z4+t6xPd+w3UvGELcl4J7O7mg39S/Pr8cUp9j1MgSYAJuDNQNCF15nSbhOLBk6meFNPq8HvCSR3FlaUtjwS+cfHjYOflXcA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR11MB4351.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(396003)(136003)(39860400002)(376002)(366004)(346002)(186003)(71200400001)(66446008)(2906002)(9686003)(8676002)(86362001)(8936002)(52536014)(4744005)(316002)(5660300002)(966005)(83380400001)(6916009)(66556008)(55016002)(66946007)(6506007)(64756008)(33656002)(478600001)(7696005)(76116006)(66476007); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: =?us-ascii?Q?wdi2fzI68YDzuUxnLH7w52P7xogyZPNzrzoLzDLIYZ0yrJe6vUVm2wCsSqZI?= =?us-ascii?Q?2ir6OGEL5Rrm9SOThqbLbuoOSGJZF5ajnqehtzKezRk4b0ZppuLiisvv5zlv?= =?us-ascii?Q?9za3+UhZaVjKzQhapggWj0RXJ4ThIooWqhaSb3+0dRbTZsM5+tzI5MpbKYO2?= =?us-ascii?Q?G4VLU/SvuO44FTycgqfERmuvQFkxkKJqlJHNIQieWTq/QgI6/FficuD9qcb+?= =?us-ascii?Q?nu5J/XFtzIYjTli+39vfdE1B6YiFl0QDY+VH/gCQ8JPHjFuRNanXN2M0z+JL?= =?us-ascii?Q?lKFForwofGt/xgXSr2Q2yQDhMBBPtu3K2QcYhLgIlUwIjCvkeMIucVuX/5gm?= =?us-ascii?Q?JEQOU6UTVrilHBiAdWeCurjGF39NVqCHt7GfiQf0HinFx2epmcZVTbT6ruOC?= =?us-ascii?Q?497KSqarFuFUCDrN5VG0osdZtb30HMiVul3x8tU+zwE2y0qbL2H/b3vCl+ub?= =?us-ascii?Q?avJxUKlEeYiqJX7EDtBy+t5VUhiFK/CgShOrHdPmdU50A0FfoasJPGQ8z++m?= =?us-ascii?Q?qrRCWZlfCscgBl0vtI7pvKhh9SJ+8RUu4y8ycLt5f5y35ZrHWC31lx8lqZ3h?= =?us-ascii?Q?GWVrIf5dKXqg3k35mQgWKHh7YW+HHiUT6R62boZ7UYjhwEnLx/98oBIrcYE/?= =?us-ascii?Q?cCb/0+j1mwBHf9N9Yi8OMLpjWq5NZXsClUzOL43KoX75mFcDeCoQ0CWKoVHG?= =?us-ascii?Q?lpDGMetnJOO76OEYOi/eFwuzAiDWV05fzJ7uCtPrJwx5ClqTRnInAEDAUxAV?= =?us-ascii?Q?aJJIURSiszFC+ReLJAHK/WNXdhMeqqnS7hCe70nms5yznEMiGeBIVrmsEjOr?= =?us-ascii?Q?gnRUz4zLYXVHkLj+4FTP4eS3fuobkxc0tI1D3+1BmYYtyB5Mgxat0PMXyDLY?= =?us-ascii?Q?4A7n/vOvXCEIvAZZrSvW467bMZEB0Y5fV1V2VG6FsZd3xyLVVCRSkpmk4fDF?= =?us-ascii?Q?d6vcOjmhnMMbCQs10Pi8Dw4X+73dmEPNMBXQSH3yzFxOMxG/hzZtYbss9Jdn?= =?us-ascii?Q?by8LChBrJ6+Bnp/sEAlTCE2V0EXmg1V1MZwcpVSj3zoRNPM=3D?= x-ms-exchange-transport-forked: True arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=VQbrBcsOmqPfYAM44TicuvKLfIWkO60xDx0HQB2evSaC6ZU0hdRs4AYZuUSII3oSRdkDVbSrpi4jfymEXj1wF8mue1+OwKq2UPzVR+fFTi4NvDim1BGiibLmiUJYa6bTlbvmDaDnBMdzBkYIquUAqqs81uv+hnv1O2/S9CI8y+ICOLjlUyHE7C66BT4i2ucqH5gwiDTdtjpFvop07d3QBBiPu0PkIjgpPoncgAvytRIe+YwU0lS7gojWw+vt2xABuU/t5lK2vsdFySdvGck+83byjsIa9/kS/xH7FmtUBQRL9k8JTBhGdHjpQ9pDnrG2nx9cf9LO/ndxZcGuc4ZO5g== 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=A2SRc0MqYD8zUUIq6aPdyX4zTFYRXqifspwfxl6Ou4E=; b=TTsNJ4Li+ltz66i+flAKilDL5ySCWg7P4oCJyUdBnpm2qwW5R1BhVmXLL5JhuomQY62K2v2HM/ACwKkilkWggz6QFwCfu2cougxlSDZgxGwIHg7phyQ1kptuuUGEKVX+bvKcA4LZE5gFB0X7iohMQfa/8tlsxBtRR7wqAEG9+pJGT71UdsEWl2Ryfzcg2e3hVQbVImprfLOp3cE8PeU8LQfxcxwGSjl45LPYaO3wRF0BZimz/0IN6O1NlhD9acDZ/uidTpgP7uspq3anqwxCBjh7YHxtzBiLf26qzPc1eZ6bcHkXnKElcRPWhwWUxQ9KbC1zWKdQnUFQikixLN0mow== arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=comcast.com; dmarc=pass action=none header.from=comcast.com; dkim=pass header.d=comcast.com; arc=none x-ms-exchange-crosstenant-authas: Internal x-ms-exchange-crosstenant-authsource: MN2PR11MB4351.namprd11.prod.outlook.com x-ms-exchange-crosstenant-network-message-id: 31592723-0c94-4315-055d-08d89924eb8a x-ms-exchange-crosstenant-originalarrivaltime: 05 Dec 2020 13:51:52.0809 (UTC) x-ms-exchange-crosstenant-fromentityheader: Hosted x-ms-exchange-crosstenant-id: 906aefe9-76a7-4f65-b82d-5ec20775d5aa x-ms-exchange-crosstenant-mailboxtype: HOSTED x-ms-exchange-crosstenant-userprincipalname: wLTH7NkKMmEi+wIOw9vnk0CQatmuEVLcpCrZ/k5cxtlWh5d8X3vWINwGKhV5H1CGom4rltLVLghefKTj2+GKtvqTOCjBqj+PuCl0ehWhOvM= x-ms-exchange-transport-crosstenantheadersstamped: MN2PR11MB4176 x-originatororg: comcast.com Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Forward AAETWA X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.312, 18.0.737 definitions=2020-12-05_08:2020-12-04, 2020-12-05 signatures=0 X-Proofpoint-Spam-Reason: safe Archived-At: Subject: [dmarc-ietf] Discussion: Removal of validation for external destinations (Ticket #76) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 05 Dec 2020 13:52:01 -0000 Hello, There's currently a ticket that suggests that the requirement for external = validation be removed. Today, if example.com has an RUA that points at exa= mple.net, the latter must create a record as such: example.com._report._dmarc.example.net TXT "v=3DDMARC1" The original thought was that a bad actor could overwhelm a target with unr= equested reports. It seems in reality, most report generators only send on= ce per day. Additionally, there appear to be some generators who ignore th= e absence of these records. https://tools.ietf.org/html/rfc7489#section-7.1 We'd like to have discussion wrapped up in about two weeks or so. Again, t= hank you for your participation. -- Alex Brotman Sr. Engineer, Anti-Abuse & Messaging Policy Comcast From nobody Sat Dec 5 09:56:12 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 072323A0A4A for ; Sat, 5 Dec 2020 09:56:11 -0800 (PST) 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 (2048-bit key) header.d=iecc.com header.b=l9ZAaERg; dkim=pass (2048-bit key) header.d=taugh.com header.b=K9nx2h+V Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3xdep_P5kPEl for ; Sat, 5 Dec 2020 09:56:09 -0800 (PST) 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 1A8EA3A0A4D for ; Sat, 5 Dec 2020 09:56:07 -0800 (PST) Received: (qmail 29848 invoked from network); 5 Dec 2020 17:56:05 -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=7495.5fcbc9b5.k2012; i=johnl-iecc.com@submit.iecc.com; bh=Bf/m1rFwKixiQjn1dY0fN++MIB7ARYSPGxAtrVjsYlw=; b=l9ZAaERgBqMI8v76KsDZgfL2+Tu8R+n3LFfEXf3QZDC7y+WeqRDizN+cJe9yCIIVpzhJrfQW9i+SbiC8SMpp3nPFMDkdR5dX/ouDnodkUSS8P8uI4BZkpV+VilwMjgVcL6ScK5S/sfOXm6yh8s/gUJNdyiUMtttx9V1sKgFbfa4jv5Qzn/Y9wZppGu2jvLxQL+GLZCCBdXaddGDt41M7c4SUxKEyTvUuXNc9/RmfCQu5++KnDT2HsLuza4Ba3z41iYWWiPenYpxL/pHtnqNhHp2nbiusBsgPAYlM1u9CWXl6pmwbj7/1C9AK2QGsZURshj+1I/pXI1AlYRcCpDQc+A== 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=7495.5fcbc9b5.k2012; olt=johnl-iecc.com@submit.iecc.com; bh=Bf/m1rFwKixiQjn1dY0fN++MIB7ARYSPGxAtrVjsYlw=; b=K9nx2h+VFZncfJNKsEwIMtn3O2aggrnnApkskbt42I422jlRoGouOl2enjtFoilcwPSzzZNRvuX/dJNwip0Tts7k54oYZT6BqPvb1Y4qmfqVOSIJYlx1DuTFagT00w6UbB3IxTpuFkYche83YoTcyqryD55vezltSgoRp1fQBxWtVUQNVxIm0RagJHFJLMDQOUcAcX7m0a4PAroXwVdxoE1JijQhm/v1GJD/Oj7Y8twnzPVONxKMHAY9B5ETuLJ/brXIDihjbnLG374CIp8jBTu0TxUe6e5KhMljZhNqYGyGVcSxGNmpH/ftMUbTUAiNVk5JWrOhvd/FzeBuU00v3A== 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; 05 Dec 2020 17:56:05 -0000 Date: 5 Dec 2020 12:56:05 -0500 Message-ID: From: "John R Levine" To: "Alessandro Vesely" , dmarc@ietf.org In-Reply-To: References: <20201202233432.D45FB28E1943@ary.qy> <479cfb50-b98e-fbbe-e7ce-375557cd624@taugh.com> <0a650f5d-c53d-ab45-4125-6491c413f70b@tana.it> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [dmarc-ietf] Ticket #42 - Expand DMARC reporting URI functionality X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 05 Dec 2020 17:56:11 -0000 >> My intention is that if you send the report by https, you're done. > The VALCHAR element in Section 3.2 of RFC 6376 accepts "/", which is seldom used in email addresses and ubiquitous in https URIs. We could convene that when a mailto is to be considered as an alternative to an https, then the former should precede the latter, separated by a slash. For example: > v=DMARC1; p=none; rua=mailto:local@example.com, mailto:report@service.example/https://service.example/report/; Ugh. Given what other people have said it sounds like it would be more useful to keep the current rules that you try to deliver the report everywhere. That preseves the ability to send it both to your local address and to someone like Dmarcian, even if Dmacian also supports https. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From nobody Sat Dec 5 10:29: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 C80D73A0B02 for ; Sat, 5 Dec 2020 10:29:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.851 X-Spam-Level: X-Spam-Status: No, score=-1.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iecc.com header.b=XBjQElr4; dkim=pass (2048-bit key) header.d=taugh.com header.b=nD2QVNcw Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w49R4mo1AUDZ for ; Sat, 5 Dec 2020 10:29:35 -0800 (PST) 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 8DCFD3A0AFD for ; Sat, 5 Dec 2020 10:29:33 -0800 (PST) Received: (qmail 36781 invoked from network); 5 Dec 2020 18:29:31 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=8faa.5fcbd18b.k2012; bh=tZ5ZD3304ouXyhdZsSmsc6TCwh43JvfDFTcIt6VyEuA=; b=XBjQElr4B+8ufunPyHaSxr5crspXAItPr2s8mHvRgAR70ksI6v/tFTYjK1eONY1TOg8DOZ9zld/bK2oEbvG2HVpXhJHqCjAITvknuk0dQi7XW+euDEV6ix+egpBRrkcKJW8SmG/KgLbDV4fhBZMkDccTZ6HWrSqtk3mdjUKsySe3mwSETz9gZ/NeD3i8PPVtFIGEUXc1dIPkxtCM7eEifJOMPs6ekCqlfsy66+fLKYaj4A6DibhRXZfF8IB4NWy9BAqDqJ8WS4Topt/wkcIp3hPI+R56gVTpzo88gNrNIgnV3uSlDIO6VLNOjOT8bw0uX7K49x5MMdSZXKNlbIfXCg== DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=8faa.5fcbd18b.k2012; bh=tZ5ZD3304ouXyhdZsSmsc6TCwh43JvfDFTcIt6VyEuA=; b=nD2QVNcwA/kVbpHOyqfZ23JJtzRcFE2qiEv1vw0AgebWasuqltZhk0brjXhwKW0/m9aFf5KIJclaxNSYA5UCsbz+PCKRFzGoZmcCa1fdR8LJFT6DjFNlwg3FYz4P++Rl41dWrfzmm+XBf2gA48/V7rdzuORwnR6UGPpVDehU+SRDviQVF150dAwzg3vLGbh0WAdk/ffTK7Ads6nhlvOJ5WFdDUNh3FS9JqEgHowM5qJHHRkf90f5HQokNMxtcugawRftsaOUOCfKS07cZ2p0xTic+poSIlCqPFNOLbuFlDhk0EiZU3PPpugUAD/WybUJ8288bZDsrOZS2sALowNDXw== 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; 05 Dec 2020 18:29:30 -0000 Received: by ary.qy (Postfix, from userid 501) id 5DFDA2900B51; Sat, 5 Dec 2020 13:29:29 -0500 (EST) Date: 5 Dec 2020 13:29:29 -0500 Message-Id: <20201205182930.5DFDA2900B51@ary.qy> From: "John Levine" To: dmarc@ietf.org Cc: blong@google.com In-Reply-To: Organization: Taughannock Networks X-Headerized: yes Cleverness: minimal Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] A policy for direct mail flows only, was ARC questions X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 05 Dec 2020 18:29:37 -0000 In article you write: >mailing list to mailing list mail is very common in GSuite, but maybe we're >a special case. I dunno how special that case is, but there are lots of cases where mail passes through multiple layers of ARC signing mutations. I routinely get mail from Microsoft's farm with an ARC seal or two that has never been near a mailing list. Any time a MS user sends a message to one of my lists, it'll emerge with at least two ARC signatures. R's, John From nobody Sat Dec 5 10:33: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 BC3FB3A0B1A for ; Sat, 5 Dec 2020 10:33:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.85 X-Spam-Level: X-Spam-Status: No, score=-1.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_PASS=-0.001, SPOOF_COM2OTH=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iecc.com header.b=W4eEY1fe; dkim=pass (2048-bit key) header.d=taugh.com header.b=MxzS4HXf Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id St5olTnZFp5x for ; Sat, 5 Dec 2020 10:33:10 -0800 (PST) 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 5DF653A0B18 for ; Sat, 5 Dec 2020 10:33:10 -0800 (PST) Received: (qmail 37531 invoked from network); 5 Dec 2020 18:33:09 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=9298.5fcbd265.k2012; bh=AnkCHMrQG5/Mn6CGQvgCy0sKtTQ/Y4GsEdiBqaNR42k=; b=W4eEY1feAei6rmE9HymN3t+/r2N4Lo9Pf4/pq7iuX2WQeYS69Q7j/7cM1QgoHKpcRxhAxtf7gb0NE50NNeUVcxO+4KZrpUHQxF65uP/H9N0aihhjCxIEEot9OrX8Q+hMbkJC+Xs16b7j9fnxxUwJXBjHG/0B9W/PNim4VlVpSj7fHzB3CkhcOE49vHmEV+xFEpk/t3RHiOopdW/FURYDSt5dS7zH3BUeVP8wIxSfQr3HgCVqS6SdcIcowYDdfHGjemSPIGy3IhAR2TW7N9yavYxsWqirlm3ncSyqcS7t5mkiI2sZa8fgxoLyrF3jS0Cc6W2herUm+yVmIf8nPqe+AA== DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=9298.5fcbd265.k2012; bh=AnkCHMrQG5/Mn6CGQvgCy0sKtTQ/Y4GsEdiBqaNR42k=; b=MxzS4HXfMH3ugPTd9o2QLu4PSVJrJWpRqQ7riM77a1HihRzMwGGc87PXwLInifvCyhZ6N+psYzkZO61xg1Pt6LgL+M+0Y3AgpObf/edz8UlqeEMbFhXD5eSGoSu7kWHOODSJa0IY06RWJs4soR2BQsx2wn7SjpJwqIMTEN0o1fqmU3gxQfvARUj69OFYBNcHJq9r4U4CwmRQUqpVL1erttJaO5P7RmgMMsVI30VF1w7ATLllUnRrqsi95MfipXlY/9a9PkrPdNRLBFG3bkHvJ6PJ+26tRaqgpDIz2JC3utdj08VUFgOr0yHdD66MOVUn+bTCxpmhhzZ19JxwTabG1A== 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; 05 Dec 2020 18:33:08 -0000 Received: by ary.qy (Postfix, from userid 501) id 622DE2900B9C; Sat, 5 Dec 2020 13:33:07 -0500 (EST) Date: 5 Dec 2020 13:33:07 -0500 Message-Id: <20201205183308.622DE2900B9C@ary.qy> From: "John Levine" To: dmarc@ietf.org Cc: Alex_Brotman@comcast.com In-Reply-To: Organization: Taughannock Networks X-Headerized: yes Cleverness: minimal Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] Discussion: Removal of validation for external destinations (Ticket #76) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 05 Dec 2020 18:33:12 -0000 In article you write: >Hello, > >There's currently a ticket that suggests that the requirement for external validation be removed. Today, if >example.com has an RUA that points at example.net, the latter must create a record as such: > >example.com._report._dmarc.example.net TXT "v=DMARC1" Whether or not the mailbombing problem is a practical problem, everyone has already implemented this check so I do not see what problem we would solve by getting rid of it. It's not like the test is expensive or publishing the record is hard. I think it may somewhat mitigate hammering on third parties when someone misspells its rua= target. R's, John From nobody Sat Dec 5 10:37: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 CE3CE3A0B18 for ; Sat, 5 Dec 2020 10:37:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.652 X-Spam-Level: X-Spam-Status: No, score=-1.652 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mtcc-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nQBVk3bPigia for ; Sat, 5 Dec 2020 10:37:40 -0800 (PST) Received: from mail-pj1-x102d.google.com (mail-pj1-x102d.google.com [IPv6:2607:f8b0:4864:20::102d]) (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 A3D1C3A0B1A for ; Sat, 5 Dec 2020 10:37:40 -0800 (PST) Received: by mail-pj1-x102d.google.com with SMTP id lb18so2463571pjb.5 for ; Sat, 05 Dec 2020 10:37:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mtcc-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=Ozs9LgG0kL0iWRzemovgDuwKi2eebgUesInkE1JaLmE=; b=kfOIpErYmuE/UFW3UiL4swunQX4p4p3nHgZZcXcGTEgYB/yqXT/fU7zcyZofZSG449 XpIQKiYZevsGxfj1JTR8179A7mOjAnj6rjhegQWwoPHKJ65keSjupKyH6fNoelPD1wSN yWOfCW4jZmp5XDzlLpwwO+w67/cV6UMm5EOkh9O7QzBpsBYLM5X7OfoOakHTsLWkQcY5 GeL/aPP9jaVFZNR3Poy0n3hSQE1xWsRXga3cqQAmkUxtfiu7saRO2NMvJ41ukm2LEsbh mHvKd0gotfDm++0qRWAp6RUJqapSkwVM42OKrs/56OFe0ryhlrlf4pMbuPpIlBKOUdJb AoPg== 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=Ozs9LgG0kL0iWRzemovgDuwKi2eebgUesInkE1JaLmE=; b=Za6k7/g9aBqpsUXe5/VJVC8E/8aQr9v1Sat044VgZ6c4J+lWjFs4uzEl0Q0xmT2Zir LUrvrpjIXkFA6QXsa9J+eVVpwgU/j9vUFmNS6brsj5s+Cv5tM9V8w2WZZT3MMTudTnEi +ILLimXtdvqw8dv7sPd5syEBHscjd1HTmxp8NWhlxR+FadkghkdYzigxfST52QuqHpAw Vxbs+RoymPPNWSq9Jocw7uPqjkkbe7ZuI2Fy3nuu+h+FVqxf2A0/KC6Szxt0QU/67PkT TS74Sj3xF1k5PgsAnVUTCBd6Fb3LQiUL24xfdamNeeFuFEFZkXYyj1jtANdjo/NagYbU korA== X-Gm-Message-State: AOAM5336hVS1Ii2KSlOO7qXNEYqFNUuIkE66Kiwu+ur+GLkDB7nP9TnX e8VarDGrhNOdgR1rLrWDmHYHdWzRfmVJ5g== X-Google-Smtp-Source: ABdhPJzeA4CQNM1eoVNno1wWCzKLyMVqAEPQNn853Rsk9x1poe4F9NXTwg8eHq9+adJg7THnzdvt8w== X-Received: by 2002:a17:902:56d:b029:d7:c927:2e51 with SMTP id 100-20020a170902056db02900d7c9272e51mr9089604plf.27.1607193459496; Sat, 05 Dec 2020 10:37:39 -0800 (PST) Received: from mike-mac.lan (107-182-42-33.volcanocom.com. [107.182.42.33]) by smtp.gmail.com with ESMTPSA id ds24sm5771003pjb.30.2020.12.05.10.37.38 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 05 Dec 2020 10:37:38 -0800 (PST) To: dmarc@ietf.org References: <20201205182930.5DFDA2900B51@ary.qy> From: Michael Thomas Message-ID: Date: Sat, 5 Dec 2020 10:37:37 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 MIME-Version: 1.0 In-Reply-To: <20201205182930.5DFDA2900B51@ary.qy> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] A policy for direct mail flows only, was ARC questions X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 05 Dec 2020 18:37:42 -0000 On 12/5/20 10:29 AM, John Levine wrote: > In article you write: >> mailing list to mailing list mail is very common in GSuite, but maybe we're >> a special case. > I dunno how special that case is, but there are lots of cases where mail passes > through multiple layers of ARC signing mutations. > > I routinely get mail from Microsoft's farm with an ARC seal or two > that has never been near a mailing list. Any time a MS user sends a > message to one of my lists, it'll emerge with at least two ARC > signatures. Getting multiple signatures from the originating domain doesn't hurt anything. It's a little wasteful, but that's it. Mike From nobody Sat Dec 5 11:50: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 C11CF3A0C3F for ; Sat, 5 Dec 2020 11:50:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.651 X-Spam-Level: X-Spam-Status: No, score=-1.651 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mtcc-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WvkonDY9GN9f for ; Sat, 5 Dec 2020 11:50:12 -0800 (PST) Received: from mail-pf1-x436.google.com (mail-pf1-x436.google.com [IPv6:2607:f8b0:4864:20::436]) (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 A90A63A0C37 for ; Sat, 5 Dec 2020 11:50:12 -0800 (PST) Received: by mail-pf1-x436.google.com with SMTP id w6so6218317pfu.1 for ; Sat, 05 Dec 2020 11:50:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mtcc-com.20150623.gappssmtp.com; s=20150623; h=to:from:subject:message-id:date:user-agent:mime-version :content-transfer-encoding:content-language; bh=OokcHjenW19WF9zqg6D17eUj5VFf0VcgvFSFjTlWiIk=; b=zrMO/D6b53OFmg6pz9T2ys9N+p0Qs6CYxcubyZiIZ6i+rmy+7UGfgPbU9A9rzNFPJO GTkfYk6NaF8W/HGWvp/B7Y6YYU+5cgKKjKrjN3AZJlwhXbyzWKBCtt/srifBoHzQjC9P GiPT5MR6TixEbhCK+HCFzBHSOcz+wToC+uZAKffJ7mfRM2nMlkEjDhEKkqWhP52vkVXJ hm2LA3lCYhhCPvuypLU5eZxOlEKZKDuXu88BkqTZ/HFRsMBQWLDXBXzj/E8koqrpmvKh JflxaGg1320jmeT+52e57gkpoDPx0JlJ1yjRiymYs1cn0OANNYtVprFkC+Z+Cup5E6ST hR0A== 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-transfer-encoding:content-language; bh=OokcHjenW19WF9zqg6D17eUj5VFf0VcgvFSFjTlWiIk=; b=gmmGtoJlxsZ0MNlBzBkIWJejaDfY+/ugegCFXIMnkMbYq016TIY9IcGy8lm1EliUp9 /tBWl26sDO0bmPzArEPtXGHPdabCeKaKveeg7HGPQQiYXl2jNownd6HXRDWGhqSXAM38 PXtNmmLeQoe+xFx9nkSsSF1HYccwThb3EMhr3T2JLP6vChMnnu8nsJp7vYz3KKYGl4Ar ie3OHmdbPwa1v1BrPAme3i2huqXbmEsBEiwvtixu9v5QsEP21lfM/CdlWeRR9H4c4Amt NTAbngO60I5rL7ShuF4pzId6iFduvv9i45sM6hxgk7Iw32H2HIdf9+8LnIYko+LJp5NK msVA== X-Gm-Message-State: AOAM533sLsA+ozOo09btMCM2YF9XLfX17NTAIyvHRjZ+02GaB5KEquao ggaA1bTBxB0jGpqlnMFfHz3lovSo7ZidMg== X-Google-Smtp-Source: ABdhPJwK1AVxK1AENE5Ew/UlO9GaNf/JWVM7A1UyYkTsxR2lqiEFOgwEcHVkY+FCGThASJxKsDUgzQ== X-Received: by 2002:a63:5754:: with SMTP id h20mr12272975pgm.378.1607197811228; Sat, 05 Dec 2020 11:50:11 -0800 (PST) Received: from mike-mac.lan (107-182-42-33.volcanocom.com. [107.182.42.33]) by smtp.gmail.com with ESMTPSA id u1sm5786376pjn.40.2020.12.05.11.50.09 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 05 Dec 2020 11:50:10 -0800 (PST) To: "dmarc@ietf.org" From: Michael Thomas Message-ID: <4f2d2e0e-c773-95df-0958-12344e963b7a@mtcc.com> Date: Sat, 5 Dec 2020 11:50:09 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: [dmarc-ietf] ARC vs reject X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 05 Dec 2020 19:50:14 -0000 As I understand ARC, it is means of transporting the original auth-res to the destination in case the origin signature is broken by an intermediary. From there the destination can decide one way or the other to override the DMARC policy of, say, reject. There are, however, use cases where that is exactly wrong and in no case does the originating domain want such an override to happen. Consider my bank sending me transactional email. If somehow somebody managed to get that mail through a mailing list and arc-resigned it, my bank does *not* want that mail to be delivered regardless of the reputation of the mailing list because something weird and wrong is happening on its face. Mike From nobody Sat Dec 5 12:56: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 806ED3A0D07 for ; Sat, 5 Dec 2020 12:56:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.851 X-Spam-Level: X-Spam-Status: No, score=-1.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iecc.com header.b=gNX0GA1m; dkim=pass (2048-bit key) header.d=taugh.com header.b=bgTNBbET Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RQHCQ3HVFdZJ for ; Sat, 5 Dec 2020 12:56:11 -0800 (PST) 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 D4D7C3A0D06 for ; Sat, 5 Dec 2020 12:56:10 -0800 (PST) Received: (qmail 73343 invoked from network); 5 Dec 2020 20:56:09 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=11e79.5fcbf3e9.k2012; bh=ZmN6SdkLVnnYMqYQw6/Copm+hFT9aeOWD30HbEmCmNA=; b=gNX0GA1ma6EQtAx39sL9zrtFqGP1E0cl/3FznPPuUIEaf9Krr3Xo7Am6hZ+Z5cWSADVUZ4uqxpLIC1QN8pkJVLJnw7LgY3boIly43WcUt6SSX6ml0Bt7GDK9HyckrDF6O86h41hjq8oKBGrpiiKKXGuXGMOhiueADbjrkVWmSKlIZzMZgfkG2o7/cM8SC55DF60MmFXQpmRFbTb7s36jmuhjmntWrG1NjQzLi/3HsvFqEUQG5NjHkap4OPqOY540VN7ujhGPnqAYpsWNfvj0ePSkixJZMc7iuXjNbFDwWkgG3cqD1WsIIc/rXVSb4pGUcJaWw1w/REFt+1FPRY29iQ== DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=11e79.5fcbf3e9.k2012; bh=ZmN6SdkLVnnYMqYQw6/Copm+hFT9aeOWD30HbEmCmNA=; b=bgTNBbETCJlZMPV4ZHdf/aE/TcGOGJl6PY4G/TZC5LM87l842GeGD7icV3F0cW++Hy4+iMAhMFlW1k8YDFoLxybSahzUZtBLMpA9Ko4zh1H123mR0+rmKUplt5Uf94ZsncVsUrxGqzuXZ9UuNXOEZ2CmpXx7ul2lvhbEgB+5xSXC10C9I804eLbfWjRDLx2tP+AMVZkoEP3BqFup2J2os6qrPOswBeu/hHMo/1DqrynDcttEe7vLrofN0Mn9aGwLDzfz/7uwdhfxA6mnc6dsTR4NAFk6xXwoCFyT7nznLEz9P5oxd7q5KTt6X2fIKuNXa89dMtavy+/2nWqermlo9g== 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; 05 Dec 2020 20:56:08 -0000 Received: by ary.qy (Postfix, from userid 501) id 7AC122904381; Sat, 5 Dec 2020 15:56:07 -0500 (EST) Date: 5 Dec 2020 15:56:07 -0500 Message-Id: <20201205205608.7AC122904381@ary.qy> From: "John Levine" To: dmarc@ietf.org Cc: mike@mtcc.com In-Reply-To: Organization: Taughannock Networks X-Headerized: yes Cleverness: minimal Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] A policy for direct mail flows only, was ARC questions X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 05 Dec 2020 20:56:12 -0000 In article you write: >> I dunno how special that case is, but there are lots of cases where mail passes >> through multiple layers of ARC signing mutations. >> >> I routinely get mail from Microsoft's farm with an ARC seal or two >> that has never been near a mailing list. Any time a MS user sends a >> message to one of my lists, it'll emerge with at least two ARC >> signatures. > >Getting multiple signatures from the originating domain doesn't hurt >anything. It's a little wasteful, but that's it. a) The point of ARC seals is that the cv=pass in seal N tells you that the signature in seal N-1 was good when the message arrived, so you can do your filtering based on the state of the message each time it was modified. DKIM doesn't do that. 2) Last week someone was complaining about the expense of the signatures in ARC seals, now multiple signatures don't hurt anything. While I agree with the latter sentiment, what changed? R's, John From nobody Sat Dec 5 13:03: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 283DB3A0D2F for ; Sat, 5 Dec 2020 13:03:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.851 X-Spam-Level: X-Spam-Status: No, score=-1.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iecc.com header.b=jp93sHWc; dkim=pass (2048-bit key) header.d=taugh.com header.b=hQjFMaOF Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WywG9NQYSr3A for ; Sat, 5 Dec 2020 13:03:55 -0800 (PST) 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 6C7163A0D2C for ; Sat, 5 Dec 2020 13:03:55 -0800 (PST) Received: (qmail 75881 invoked from network); 5 Dec 2020 21:03: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:cleverness; s=12867.5fcbf5b8.k2012; bh=tBcey6NcYNlhor1YjA49KQTjTtkPJxdPyRaPrUFKreI=; b=jp93sHWcFWpB5zV18kcfPWYENP3kesfsFyWFtHnOtQ4xqZhtGDWFy3FayZjnpwwcqVo5LoWj9t8LZDt+FFFNtTT0AtiLD6WZBk44wUEQLWyG+FpGp649Z3xZE4YfmQCW4RtfFol5fsVnc7vKu7LrLXLikj42eOm9kB66HDYM77ftzSghllT2CGYdeC5QYsAyTil3fXJ8cNiGZU93O4ZJAjGNGetTR/eHAlojTi4Fn3CjpKbAudXUt2j7lXcW9mQg5bWjzeOSnz6zVeY51wbIVRUkOY5SnZbh3y7QfbtDM+eqT+xX2R2kxZHFqEzbbs13gjvTv0BcDImKGOC0RYLrFQ== DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=12867.5fcbf5b8.k2012; bh=tBcey6NcYNlhor1YjA49KQTjTtkPJxdPyRaPrUFKreI=; b=hQjFMaOFE8DTdLFK4SrPQPxSf2KGadu02Eth4VZ7Ln9ytfdrsMrs6zx08jk8/5qISFtzws1KKsiKiZYkpe7w8ItEni7dhsuF2B8Qg/ODJcTHZqqxaOsxUbGgBaV53sRgic+rJpZuJngI6rXvCAv5re89gvYId8gR2qCznVPu/LVTzXLsSx4dO6S9CyELZQp6uZ5Tehd9a21GrRTmuUr4IWBrf3teVN2RyT2ZESuia32rKOMg7FZuNPz+YXHvItnkcqhU2ZxqZTkKkBNntORYg+xPpUdiWHBM60v3vJMGOzMsdu1/ID6mqUctoO4cLdGFg4ly3bfIXhFa8DUNnJfCYA== 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; 05 Dec 2020 21:03:52 -0000 Received: by ary.qy (Postfix, from userid 501) id DB78E2904420; Sat, 5 Dec 2020 16:03:51 -0500 (EST) Date: 5 Dec 2020 16:03:51 -0500 Message-Id: <20201205210351.DB78E2904420@ary.qy> From: "John Levine" To: dmarc@ietf.org Cc: mike@mtcc.com In-Reply-To: <4f2d2e0e-c773-95df-0958-12344e963b7a@mtcc.com> Organization: Taughannock Networks X-Headerized: yes Cleverness: minimal Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] ARC vs reject X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 05 Dec 2020 21:03:57 -0000 In article <4f2d2e0e-c773-95df-0958-12344e963b7a@mtcc.com> you write: > >As I understand ARC, it is means of transporting the original auth-res >to the destination in case the origin signature is broken by an >intermediary. From there the destination can decide one way or the other >to override the DMARC policy of, say, reject. Right. >There are, however, use >cases where that is exactly wrong and in no case does the originating >domain want such an override to happen. Consider my bank sending me >transactional email. If somehow somebody managed to get that mail >through a mailing list and arc-resigned it, my bank does *not* want that >mail to be delivered regardless of the reputation of the mailing list >because something weird and wrong is happening on its face. If you get a message from a bank via a trustworthy mailing list with a valid ARC chain that starts with a DMARC pass, that means someone at the bank really did send the message to the list. I don't think it's our job to try to guess whether the bank's users are following some internal policy we can't see. In practice, I can tell you that many organizations publish p=reject because it is "more secure" and have no clue about mailing lists, so it's a feature that ARC lets their users participate in mailing lists without totally ignoring their DMARC policy. Ditto organizations that publish p=reject and only have SPF, no DKIM, so all of their mail fails when it's forwarded. I can tell you this latter situation happens a lot, particularly in US government organiations where DMARC is just another checklist item. R's, John From nobody Sat Dec 5 13:04: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 D67933A0D2F for ; Sat, 5 Dec 2020 13:04:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.652 X-Spam-Level: X-Spam-Status: No, score=-1.652 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mtcc-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Col_CGsiZDCH for ; Sat, 5 Dec 2020 13:04:42 -0800 (PST) Received: from mail-pg1-x52f.google.com (mail-pg1-x52f.google.com [IPv6:2607:f8b0:4864:20::52f]) (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 C19843A0D2C for ; Sat, 5 Dec 2020 13:04:42 -0800 (PST) Received: by mail-pg1-x52f.google.com with SMTP id o5so5770867pgm.10 for ; Sat, 05 Dec 2020 13:04:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mtcc-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=MFmr6vTs0d15vC8jZ/VouoPz4EZt4gPkEQEotu3Kdi0=; b=I5ts9VCeJrRW9CBbSSujWZVR00nla2hkJiILPQtZp/w5fQ2Szx7W4OVlSg5XP10nP1 TTAzDAz5ZuG/pi+TQoSYjqRpNIaurPN1FigVPVret7Z9ifgyK6SsK/vrOyPS3RgPeKvv F8A6q8h8e6tXrhlqMzfDnZRSZSdbNWJPmzmHJjJCLVtjt5x80HOtkdffZslohHUpLPyZ 9rTKxZTWLVrUBaggxrCts7ddterQPht7QrCP0wd1WZhVPRQXEzJwddX/AHyCv8+vgXIM CWQXGGuUdJ2wrmH8YyRW6bCREfnfVwjZOjfHSPJE4nW+cFtpLbfFhfK7WHE4S3bvC+AS GbQA== 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=MFmr6vTs0d15vC8jZ/VouoPz4EZt4gPkEQEotu3Kdi0=; b=X3vTaagvPUX+HP7Oc1HUE8mv6d8GOEuhJ3klnBWyGDIOGXXyWgtMJsoj3xj2CNGqvf MvtL7EuyDYgKPUvBsCeBtEjsrE1jPOdnCePG+iVTWbcuZmaf+vGSc39jgzT//2cXOjkC pUlPnzNyh82VyD3+C5WTVbLWnv2layjZgde24VaY9N34c7Sr6L0H6OW1qEgxAFYjl4Dw QrT/s6SGJvQzjXLjvZYEYMyE1+88p1XOhOQY0mokktWeVVqroQ5mi98njDpf+7PCvf3e pj4sX9s1IdEXQwdb1dzlgTMMeN3bDGpMkkN7UnQNJjKbNM3FFBZa6suvtbP2IndCO0Yf YfAw== X-Gm-Message-State: AOAM531DrQpGsNoE9iDvtJqrSVBLIkgOTvoyfWjCTTi0TXLxNJo6nva1 x3CFFcE3fDwG64a5qA+Zc/IZDuv8kRELfsNa X-Google-Smtp-Source: ABdhPJyXGm0xTuVjyUx6IE6hed8G52xOQA/hHkLxWWYrADQ8ns23vm40yZ1fryPl4YQGEGCNisL1qQ== X-Received: by 2002:aa7:9699:0:b029:18a:e057:c44 with SMTP id f25-20020aa796990000b029018ae0570c44mr9551169pfk.34.1607202281790; Sat, 05 Dec 2020 13:04:41 -0800 (PST) Received: from mike-mac.lan (107-182-42-33.volcanocom.com. [107.182.42.33]) by smtp.gmail.com with ESMTPSA id gm2sm6061574pjb.35.2020.12.05.13.04.40 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 05 Dec 2020 13:04:41 -0800 (PST) To: John Levine , dmarc@ietf.org References: <20201205205608.7AC122904381@ary.qy> From: Michael Thomas Message-ID: Date: Sat, 5 Dec 2020 13:04:39 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 MIME-Version: 1.0 In-Reply-To: <20201205205608.7AC122904381@ary.qy> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] A policy for direct mail flows only, was ARC questions X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 05 Dec 2020 21:04:44 -0000 On 12/5/20 12:56 PM, John Levine wrote: > > 2) Last week someone was complaining about the expense of the > signatures in ARC seals, now multiple signatures don't hurt anything. > While I agree with the latter sentiment, what changed? > It means that you can't control somebody else's infrastructure. We can control whether standards are created carefully and thoughtfully. Mike From nobody Sat Dec 5 13:06: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 08A463A0D32 for ; Sat, 5 Dec 2020 13:06:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.851 X-Spam-Level: X-Spam-Status: No, score=-1.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iecc.com header.b=oFp6Dh1C; dkim=pass (2048-bit key) header.d=taugh.com header.b=gssfHKQ2 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qJ23JtMgZgOj for ; Sat, 5 Dec 2020 13:06:41 -0800 (PST) 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 0744D3A0D31 for ; Sat, 5 Dec 2020 13:06:40 -0800 (PST) Received: (qmail 76614 invoked from network); 5 Dec 2020 21:06: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:cleverness; s=12b3e.5fcbf660.k2012; bh=e2P4RU8hFOL2lxzwj4qggHHvo2mFLakydsdu4lsMQAk=; b=oFp6Dh1COMH18DwzchiI46JXpPB9eoLk0IMme/IzfwX1R6fVQta5Tp2oAxHymWTDIOATBhLiCf4Xbm1Yn6vFt1kGYEcYMWEiEDfiW7fnYC74tAoXnY4xTJFX48V4EJsGA+ytxinsXSSANIE8I69i9bFKhW6JHzb+hPJoW9LWtx8LnSWO5ZBUP+9KxiqN8qOJKpZAlcWo+mEP9B6p3sBIeDQCBUunYD3yHXdBpOaXyIWJu/t88cNSfq9b0jGZy7fL3tIRwaBDrbHlk++gXqy7WRtmbeI3NiJPwVFj7jIC2uROniCLqe5f/C8lGR1seclf3jkkAbWAUSZRJSuIZ3yC/Q== DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=12b3e.5fcbf660.k2012; bh=e2P4RU8hFOL2lxzwj4qggHHvo2mFLakydsdu4lsMQAk=; b=gssfHKQ2l/2SPj0CzFkShBtoLgDEpTeCoHI6PPeNMbYXghyMkwAA5iwLwiNOryZBkRhD1sfRtja8AtgRm19r5KEpvc5//3P6joXFhON9C+PzueY716VtgU2KYdTEb43nBfk5sYeN6aHeKmWePByicrcrIP5qrY3ux/D7aiP2fHcaAIyCUEQQwWo+E0macmrupRqzt1rMtjn/GpEGTGFuis5/xGRjUEXXolpysD+rqd7mUI7IOIWW7WcjyARWstAyYcvi2521LQTtTfWv3rd1y04PiJdjeHXycFNYlu9pEgdOL+0UBPgqfbq5MQu3FgaupmIxxFfHPukfS+nVb5H5/Q== 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; 05 Dec 2020 21:06:39 -0000 Received: by ary.qy (Postfix, from userid 501) id 54261290454A; Sat, 5 Dec 2020 16:06:38 -0500 (EST) Date: 5 Dec 2020 16:06:38 -0500 Message-Id: <20201205210639.54261290454A@ary.qy> From: "John Levine" To: dmarc@ietf.org Cc: vesely@tana.it In-Reply-To: Organization: Taughannock Networks X-Headerized: yes Cleverness: minimal Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] Ticket #42 - Expand DMARC reporting URI functionality X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 05 Dec 2020 21:06:43 -0000 In article you write: >>> Got it.  However, the spec says it's a list of addresses to which aggregate >>> feedback is to be sent.  When there are multiple entries, up to now, reports >>> are sent to each. ... >The VALCHAR element in Section 3.2 of RFC 6376 accepts "/", which is seldom used in email addresses and >ubiquitous in https URIs. We could convene that when a mailto is to be considered as an alternative ... If we want to do something like that, I would overload the existing !size hack. For example, add an "f" for finished flag and say that the URIs are conceptually processed from left to right and if you send your report to one with a !f (or !10mf or the like) flag, you can stop. Still not convinced this is useful but it is slightly more backward compatible. From nobody Sat Dec 5 13:13: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 50E263A0D69 for ; Sat, 5 Dec 2020 13:13:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.652 X-Spam-Level: X-Spam-Status: No, score=-1.652 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mtcc-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7yirQKSYl37l for ; Sat, 5 Dec 2020 13:13:05 -0800 (PST) Received: from mail-pl1-x632.google.com (mail-pl1-x632.google.com [IPv6:2607:f8b0:4864:20::632]) (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 12D5E3A0D68 for ; Sat, 5 Dec 2020 13:13:05 -0800 (PST) Received: by mail-pl1-x632.google.com with SMTP id t18so5063482plo.0 for ; Sat, 05 Dec 2020 13:13:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mtcc-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=JT3yijrIWhDVy9iB7q4NcvnKsUnKIY3rzlMckCyrSpQ=; b=OEzys/04vQpxGKzyY54RmECkroIA8xWlj5+zBGkdn75SEHKJRmWJSNeoiU1iDOTPpF ocPDAILAw8yGv8tl0cUrRhj8Fe6is96EuXeTkZQun6RR9g/WHmM6V1QxaYD2P7Lk4/mE AtJNEjPCjCzGXj4PCYwTG2TUFzgF28QJSuLGPc43RDEG+ZD56ARm/5i5ASA8zdLkmnUS Zb9PrdGLmR8WW82W0uh7WYiuHhpEJ1OwsPbKydtpzWO80B3VY4KcPNtZ/Mg2FKw+fqdk rXuPUFiO+lgwr6H2/W3aPfa8SCesdhUemFqhArZNIz5qHJO1Q4W2qxV6C1REL6CdS1BR 4WoQ== 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=JT3yijrIWhDVy9iB7q4NcvnKsUnKIY3rzlMckCyrSpQ=; b=BcqBbwoK7aXZJwCQV+A63fm/kauj+8LKrl71b0QwkK2SdjTqEjb5VeTurMQR60N0UR yMCcHrJHB8EYpY0eAy35yS5BuaFcDLGgpX/xEpOcdAjd+/OurtuKwq8/6Nit2f+G1WxY pA6m6VNqJe/MgLTd7OsoJrayhp1KJ+yEOu6Sb2DtvoxsjgisDTJQtZ3DcS/avWc54fX9 inGG9YLwwvGRItIAdIh14nhOhOsf6B2YRKq67AP38h5Z6B71wa1tQxQseTKpQko4zMpB 9jNideDmEi5ejqh/eda6e92UNFokf5+ccq2cYk6CEgqRD2H8kNdI0JDmrYvZXk9etc+g MD2g== X-Gm-Message-State: AOAM532KvWjBU020Uk8GQ4qmhmic7QasoGcfi3UxMhPJdDJVy88N1TVA oULIKBh6ZPpQVNFCBiK/93GKGnFi4RBtfCiT X-Google-Smtp-Source: ABdhPJw1q12fqpjjhAkO73pN3CxKZL5bIKMDjltGllN+mQzXIxWq0sy0TlCze4gE0F9xMn44LXkvDQ== X-Received: by 2002:a17:902:8b8c:b029:d8:de6f:ed35 with SMTP id ay12-20020a1709028b8cb02900d8de6fed35mr9545150plb.36.1607202784135; Sat, 05 Dec 2020 13:13:04 -0800 (PST) Received: from mike-mac.lan (107-182-42-33.volcanocom.com. [107.182.42.33]) by smtp.gmail.com with ESMTPSA id c193sm9159466pfb.78.2020.12.05.13.13.03 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 05 Dec 2020 13:13:03 -0800 (PST) To: John Levine , dmarc@ietf.org References: <20201205210351.DB78E2904420@ary.qy> From: Michael Thomas Message-ID: Date: Sat, 5 Dec 2020 13:13:02 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 MIME-Version: 1.0 In-Reply-To: <20201205210351.DB78E2904420@ary.qy> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] ARC vs reject X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 05 Dec 2020 21:13:06 -0000 On 12/5/20 1:03 PM, John Levine wrote: > There are, however, use >> cases where that is exactly wrong and in no case does the originating >> domain want such an override to happen. Consider my bank sending me >> transactional email. If somehow somebody managed to get that mail >> through a mailing list and arc-resigned it, my bank does *not* want that >> mail to be delivered regardless of the reputation of the mailing list >> because something weird and wrong is happening on its face. > > If you get a message from a bank via a trustworthy mailing list with a > valid ARC chain that starts with a DMARC pass, that means someone at > the bank really did send the message to the list. I don't think it's > our job to try to guess whether the bank's users are following some > internal policy we can't see. There is no guarantee of that. If my bank says reject that mail, I want my provider to reject that mail, period. No amount of ARC shenanigans should change that policy. > > In practice, I can tell you that many organizations publish p=reject > because it is "more secure" and have no clue about mailing lists, so > it's a feature that ARC lets their users participate in mailing lists > without totally ignoring their DMARC policy. I'm not talking about misconfigured mail systems. I'm talking about a policy state that is not in the current set of p values. Mike From nobody Sat Dec 5 14:02: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 176B33A0DDF for ; Sat, 5 Dec 2020 14:02:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.851 X-Spam-Level: X-Spam-Status: No, score=-1.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iecc.com header.b=rLd980Ho; dkim=pass (2048-bit key) header.d=taugh.com header.b=m6YFWYUd Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1jo-n56d_Dtg for ; Sat, 5 Dec 2020 14:02:38 -0800 (PST) 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 E47663A0DDB for ; Sat, 5 Dec 2020 14:02:37 -0800 (PST) Received: (qmail 86268 invoked from network); 5 Dec 2020 22:02:33 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=150fa.5fcc0379.k2012; bh=XJGRQIZi/6Sv1eYpxND6tzyjno4BK3Zs+l53sfinxWs=; b=rLd980HoTLDIo6lZDTeJJYXuu/R0oOB7D+exM5bzhNIC/KKF4YPe5CKolH3zJsyZglYhd7MTjEN+CUuTpElOmtLI38eSAwNlC1khkfJQRM5z0C3OTwM9FDrLDKAaBqrWk7sTuOhI6fggGFoS1H6SGKZvRV4ayPO6SpUmN/SSqkZyn8mNO7cHN7wyTNeqHWSrG9BwO4t6CGZGQoLywY/kF/FmKnoBr/qWrKT55YEeQ2SQvGXODLKiKz8Sq8JBe0yCPs4Sz+NFqY7f0W1jO6g+s7zrSksOyHCmfq7pi1Jc8qJrSuGy0Tau+TisY7C9ggi3L2q9rtLDnxnwU0JIaP67mg== DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=150fa.5fcc0379.k2012; bh=XJGRQIZi/6Sv1eYpxND6tzyjno4BK3Zs+l53sfinxWs=; b=m6YFWYUdhB2YpzPzqf0JcOQc6zIhQK9sazNQbzuWLCUha82jaWpuhgA9hDOlpDlsnJsgr1/qT24/lwKNt7NudRF5nvPaxvFH7YEyUsEsuuRVNQ5YQ5dG21qNXPoPlEcm14G0sofUjU11xL9+Hhd1Mh8dQEYfG03NWwvnxkFPNd0iBhsET5+E0zJdWyb4ujUWpIGfw89U5XA5+CGzmLnGfkoIstzq4d+WykNv2SDiNkuhVu97vE8rxrRhJqlXgnTw5w1Tqz+v1B8AYffF444SmMsKGtu4jVuK2oDl7vQ9EAPsFrr5VodWip4wxYmoC5Ba1zKiNG8ZEh+U9fOEahtX4A== 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; 05 Dec 2020 22:02:33 -0000 Received: by ary.qy (Postfix, from userid 501) id 18DCA2904B56; Sat, 5 Dec 2020 17:02:32 -0500 (EST) Date: 5 Dec 2020 17:02:32 -0500 Message-Id: <20201205220233.18DCA2904B56@ary.qy> From: "John Levine" To: dmarc@ietf.org Cc: mike@mtcc.com In-Reply-To: Organization: Taughannock Networks X-Headerized: yes Cleverness: minimal Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] ARC vs reject X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 05 Dec 2020 22:02:40 -0000 In article you write: >> our job to try to guess whether the bank's users are following some >> internal policy we can't see. > >There is no guarantee of that. If my bank says reject that mail, I want >my provider to reject that mail, period. No amount of ARC shenanigans >should change that policy. OK, ARC doesn't do that. This does not mean that ARC is broken, only that you appear to have different policy priorities than other people. As you know, DMARC has never obliged recipients to follow senders' policies so this is nothing new. My system does a lot of forwards of SPF-only p=reject mail to addresses that belong to individuals, e.g. clerk@mytown.ny.us to the town clerk's gmail account. No matter how loudly someone might shout that I should never ever forward that mail, I will ignore them, because their policy is in this case silly. We have seen that senders often publish policies that have silly effects and I see no reason to pay them more attention than they deserve. R's, John From nobody Sat Dec 5 14:07: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 DBC033A0DDD for ; Sat, 5 Dec 2020 14:07:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.651 X-Spam-Level: X-Spam-Status: No, score=-1.651 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, 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=mtcc-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0bl4KUC__PNo for ; Sat, 5 Dec 2020 14:07:15 -0800 (PST) Received: from mail-pj1-x1034.google.com (mail-pj1-x1034.google.com [IPv6:2607:f8b0:4864:20::1034]) (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 CA4903A0DDB for ; Sat, 5 Dec 2020 14:07:15 -0800 (PST) Received: by mail-pj1-x1034.google.com with SMTP id v1so5161102pjr.2 for ; Sat, 05 Dec 2020 14:07:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mtcc-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=ZGp+5MxgVxn4ACkQyH5DKkyrx49BGbiDzYoSSYcdwUg=; b=dtQ4aHtAVRiX7T5/uZ7cS7x7/iQpDr0GS3wVk9l3Gru1Q2vsgOzEVla1+5hJjYyNii ptIcxglNe0D4HwtGvBm7FRD5fywsxHxHKSGwP+01P9kbwpJHDxruwWqiR/hUyAJrluus C3rzYGZiVtEvZDJeV4b8FTP6nCDsL73+A/XmBtqNeS8REUcPZZL7RAAKVDIiTk56LW0v YrY38l5zwLQWsmQceleP9JracUHxSVB1Q20/fsyfYkIWYULQ2JlQf6ylAT8AS6QCENkX Q6g7T5HbE4m16/4Ix1xNBCnabynlcsAQAfZ6y4x/lluYlZi9X0gd7O4fQigUbwWgl6k8 KVLQ== 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=ZGp+5MxgVxn4ACkQyH5DKkyrx49BGbiDzYoSSYcdwUg=; b=PxHFXhYtUJnyRFfsJw9SYNMTDdmvmSKBE0DaQipImRwLRyPgrP2dn/3M3Tj9qkQciM z2BSpyofRlMk26zaQbx4TRIwNtLDDSxQKkW02xpFNeguPNLgirGZOKUtiCpOmHoRYupw 1yIzMJjXG6hZmBVl9G8e+r1UOmSYFXH5r8F6yZPnBSdvph9J6FI1JyQ+/b8KRwF8VjYa 5FWSq4xBWbTtMXmmb4aDVioRbENbMT+lxKaGzCLnx7G1t8Bkfgn+nzFpkYAW/L957/+u Xpyt3TGrsEV6GdQkV+lTMgm5TcACqb0lJeCCxEhe8lFsoBm6xFj+Z8vm78aerHUdZSV7 /UkQ== X-Gm-Message-State: AOAM533cFaHXdRoqEXj+tuJN8lvAR8ERAEJVvUQEHU1A9xnWaHWAs03a KpeAIqvhZm03AjucfgR4zBakkf+ZXbnbD7QF X-Google-Smtp-Source: ABdhPJyD1hS1PSzjuD22PGI5DZxXoWNzxxCDlsv8b6P7i9m0w1dPrulLTYjj++bKovyDMTgiC7QOlA== X-Received: by 2002:a17:902:5581:b029:da:a547:b6a6 with SMTP id g1-20020a1709025581b02900daa547b6a6mr9301466pli.78.1607206034826; Sat, 05 Dec 2020 14:07:14 -0800 (PST) Received: from mike-mac.lan (107-182-42-33.volcanocom.com. [107.182.42.33]) by smtp.gmail.com with ESMTPSA id b24sm5975882pjq.10.2020.12.05.14.07.13 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 05 Dec 2020 14:07:14 -0800 (PST) To: John Levine , dmarc@ietf.org References: <20201205220233.18DCA2904B56@ary.qy> From: Michael Thomas Message-ID: Date: Sat, 5 Dec 2020 14:07:12 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 MIME-Version: 1.0 In-Reply-To: <20201205220233.18DCA2904B56@ary.qy> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] ARC vs reject X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 05 Dec 2020 22:07:17 -0000 On 12/5/20 2:02 PM, John Levine wrote: > In article you write: >>> our job to try to guess whether the bank's users are following some >>> internal policy we can't see. >> There is no guarantee of that. If my bank says reject that mail, I want >> my provider to reject that mail, period. No amount of ARC shenanigans >> should change that policy. > OK, ARC doesn't do that. This does not mean that ARC is broken, only > that you appear to have different policy priorities than other people. > As you know, DMARC has never obliged recipients to follow senders' > policies so this is nothing new. If ARC is advocating for a bypass of p=reject that introduces a new state. If my policy is reject, I want you to reject the mail. If I want you to reject the mail unless you think it has come from an acceptable place with receipts, then you need a new policy tag like reject-except-valid-arc. Mike From nobody Sat Dec 5 15:11: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 2ED393A0E3A for ; Sat, 5 Dec 2020 15:11:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.851 X-Spam-Level: X-Spam-Status: No, score=-1.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iecc.com header.b=eQ48zR/d; dkim=pass (2048-bit key) header.d=taugh.com header.b=LZKxrHVH Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BqiY3J6spL9A for ; Sat, 5 Dec 2020 15:11:02 -0800 (PST) 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 D1E6C3A0E39 for ; Sat, 5 Dec 2020 15:11:01 -0800 (PST) Received: (qmail 3723 invoked from network); 5 Dec 2020 23:11:00 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=e84.5fcc1384.k2012; bh=1KDVbMT0DZcKoXyvNGbz9gt5XthoVz25NSkDOMrH22Y=; b=eQ48zR/dbvscTHneCMMTd4I9LaCfOLwQ7hLX9qYTDzs5t3rQUQLQH7I26eDxnhocUqtkeUfF9Y5fDFbr3gxJPfPxYOmUFjSMaNYMkhfqfy+xD7tsOoRKNmpM0LPIXjHC3WxOxlyapsxFaSX83rWOoBbqxFJv0IqieHNbCLJwh7NJ/SCbww2ErslghRvg8p4KIlp6ZZsj/Bw//GlNCznlSF+RK9pqSVzbEVMA0FtGOgyzJ7sVmFdofAX3a8wQdsa7274FhBy5PH52fAnOrdLMQ2bbi5wc7AluM0amLmj1NHk9rJ8N8ik9oGQUunbNS4L0u9BX1/PDCradaLCyKCN0lw== DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=e84.5fcc1384.k2012; bh=1KDVbMT0DZcKoXyvNGbz9gt5XthoVz25NSkDOMrH22Y=; b=LZKxrHVHgTt5IkQ8YM6USFQ3ycHLzb3034HelnRVDBv5tKxM5aEZ5DI3YAi3nzcLtJS+eGQ9eI1mwzo+F/SlNFi1mPKe9VStVEWHKNp23zKzGcMWJC58Yht1GkBFRuEQ65jFZylWdm4VNN9jK68TZSTrrFiDbdd0n4V3sfX6HVQEd9rJV9j7VDQ/kKe7v27RdwgW3gdMA2DDDlNtoOKTcwiJ/2WxMvwu3rhwmRIL1Xbt8dFlFKFEI8+S1aZvyG08Yzw6Gtp2lzI8lmsmgziVDi9Jl33PPGfaXifnPAjnX8Y+Q4Pa0ik7D9gvqtSgEmdj5CHX7EZuzo8Rmy4ohnW8Zw== 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; 05 Dec 2020 23:10:59 -0000 Received: by ary.qy (Postfix, from userid 501) id 2BA23290EDCD; Sat, 5 Dec 2020 18:10:58 -0500 (EST) Date: 5 Dec 2020 18:10:58 -0500 Message-Id: <20201205231059.2BA23290EDCD@ary.qy> From: "John Levine" To: dmarc@ietf.org Cc: mike@mtcc.com In-Reply-To: Organization: Taughannock Networks X-Headerized: yes Cleverness: minimal Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] ARC vs reject X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 05 Dec 2020 23:11:06 -0000 In article you write: >If ARC is advocating for a bypass of p=reject that introduces a new >state. If my policy is reject, I want you to reject the mail. If I want >you to reject the mail unless you think it has come from an acceptable >place with receipts, then you need a new policy tag like >reject-except-valid-arc. Other people will have to speak for themselves but on my system a) I don't believe you. 2) I don't care. I think you will find this reaction pretty common. I see lots of mail going through my system like the stuff I described for the town clerk. It is obvious who it is intended for, the only way to deliver it to that recipient is to forward it, and if the DMARC policy says not to do that, the policy is wrong. I don't even need ARC for that, although ARC can be useful for mail that takes indirect routes for the mailing lists they subscribe to. You can say, no I am smarter than those guys and I REALLY REALLY mean it, but see 2) above. R's, John From nobody Sat Dec 5 15: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 3CD933A0E4F for ; Sat, 5 Dec 2020 15:15:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.651 X-Spam-Level: X-Spam-Status: No, score=-1.651 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, 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=mtcc-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oRs6-fybcwIU for ; Sat, 5 Dec 2020 15:15:57 -0800 (PST) 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 0AB853A0E4B for ; Sat, 5 Dec 2020 15:15:56 -0800 (PST) Received: by mail-pg1-x52d.google.com with SMTP id m9so5909478pgb.4 for ; Sat, 05 Dec 2020 15:15:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mtcc-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=lSFNaCZxpxPTz0DsPPcGy6pPsLb4kJNaOXAO+G7PNpA=; b=uDdGVcKQa9Ipnc3PhC1A13Sioztfi6pHc+Q57X40SYpCjvklLsyD3Kqw2aIlTdtUSg vU8Ln8Vv8ZMJhrg5MUhKITVZcRJb1htcAf6CzjkTY/e1MPu7TFi+DKOVqybV8ciTm0Cg 6v+Hj08b6hzJDgj+l6Gkoke+T2yyqFNIRhTyg2anfiGPvaF6VdMOqHHgduC80aEYz/QD neEl0tEiyWEPNTzzanlYR5VyrgWYAxomuDxr4XPtG8jose4oV9dAjqmsssPiVjyhTVyJ 0L+2ysrpWRhNG7JjYLOoa/gYh/fTne5/E5lCb7/trwZeEtgEUj4aOi6FMvaxDizWs3r3 zfTg== 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=lSFNaCZxpxPTz0DsPPcGy6pPsLb4kJNaOXAO+G7PNpA=; b=eEWfZNUd7a9DL3dmDw9eUKnZy3N1F4uNpeht+cJqJWp5xTC/k0pD+e3wJc3KyYFIiz Ok/2jSHZ5KFRDdJuB0ISvQ2Jy4FhyMgJgPZDSdIZCksYgiv93lRWT/0O0o+lVm2DZCnr rLpyzNNIkf2942XRHq3fIrvofjQeTpM3tMC6LbSNxycpKGzEXbqcnKZdQdV0ImnG2gwv RRHjKtozHpYMfAEuaRxzflQgyOQQElAayX1gw+udns5a6+7ztJ68SPynQNCAQLzdTqcy wLA7xHAiGAHxA2d2emXNUsGLzKoNexLjxj6iZgLNrjcADwouqgND9UpP0vGFNyLpkFbR gqkw== X-Gm-Message-State: AOAM530zbPuAVE5Lavc5kQOR9R30vrjU7LLZFZdukrmX0e0bns3e58UW Q5rjYB9FwqrojK3FpCLFU+qGKyVrqxD5Wh7/ X-Google-Smtp-Source: ABdhPJx/NG91a65f6Dv5i2GfEUejHQ1V7II9nPackH4KnSMbE637z+VH+NvEftiV2knSwnL79t85Bw== X-Received: by 2002:a05:6a00:816:b029:198:30d:e020 with SMTP id m22-20020a056a000816b0290198030de020mr10305981pfk.52.1607210156004; Sat, 05 Dec 2020 15:15:56 -0800 (PST) Received: from mike-mac.lan (107-182-42-33.volcanocom.com. [107.182.42.33]) by smtp.gmail.com with ESMTPSA id 125sm9377036pfy.111.2020.12.05.15.15.54 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 05 Dec 2020 15:15:55 -0800 (PST) To: John Levine , dmarc@ietf.org References: <20201205231059.2BA23290EDCD@ary.qy> From: Michael Thomas Message-ID: Date: Sat, 5 Dec 2020 15:15:53 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 MIME-Version: 1.0 In-Reply-To: <20201205231059.2BA23290EDCD@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] ARC vs reject X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 05 Dec 2020 23:15:58 -0000 On 12/5/20 3:10 PM, John Levine wrote: > In article you write: >> If ARC is advocating for a bypass of p=reject that introduces a new >> state. If my policy is reject, I want you to reject the mail. If I want >> you to reject the mail unless you think it has come from an acceptable >> place with receipts, then you need a new policy tag like >> reject-except-valid-arc. > Other people will have to speak for themselves but on my system > > a) I don't believe you. > > 2) I don't care. > > I think you will find this reaction pretty common. > > I see lots of mail going through my system like the stuff I described > for the town clerk. It is obvious who it is intended for, the only way > to deliver it to that recipient is to forward it, and if the DMARC > policy says not to do that, the policy is wrong. I don't even need ARC > for that, although ARC can be useful for mail that takes indirect > routes for the mailing lists they subscribe to. > > You can say, no I am smarter than those guys and I REALLY REALLY mean > it, but see 2) above. > Can you keep your contempt for me off this list? This is not even responsive to what I wrote, and is nothing more than an ad hominem. And  your anecdotal evidence drawn from a tiny system is very suspect. Mike From nobody Sat Dec 5 15:24: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 5D1823A0E62 for ; Sat, 5 Dec 2020 15:24:21 -0800 (PST) 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 EnLl8l9a1Ukw for ; Sat, 5 Dec 2020 15:24:20 -0800 (PST) Received: from mail-pf1-x432.google.com (mail-pf1-x432.google.com [IPv6:2607:f8b0:4864:20::432]) (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 1C2703A0E60 for ; Sat, 5 Dec 2020 15:24:19 -0800 (PST) Received: by mail-pf1-x432.google.com with SMTP id f9so5825177pfc.11 for ; Sat, 05 Dec 2020 15:24:19 -0800 (PST) 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=j3eqkB9yAkukOffgtxx8Y0F8RQ26ov27rnR9YLAe4Gg=; b=tLy+XgffrK6MhZGskc2upjEkm6CcXMRDhJwkQpqpQAR9tE3j637dRCqLhwUijm24et VtS/IWln65nTEVDQ60D2FGgPwxLlU8Vzu59qD90tepzNORHSHWRcPJS2jWBkVJVRctp/ shnJV49Mzjs2DIl/fNc41+lOzaKW8Nw078bZzngy55WSa44JysWlMa9H4/yH4chYqXnW ROIopAuy9wTOEepo2JUkY05LXScef3UVvBY9Tng8PqwiWPBITuu0P9GEEQJTUgqDD/bX tp0fwH2RRwmbnjxlEBZXWkMSBPf6nt4p3UeG9Lj43otZp+mJkRP2fBq1BU3i0sd8C4Yn ytgw== 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=j3eqkB9yAkukOffgtxx8Y0F8RQ26ov27rnR9YLAe4Gg=; b=ZEwDuTSk9vQ07XCx22TweoDvRaB8kLYtcLHRBhgs049d+JtXfmTVlF/peyduL3MLU6 aavyQJtT8NYHJw/qnligBcA6C+wdI6+044IyBJ3bcG9rh9OY/abBiXTreSN9qEgcOaV4 yti60dmUjbvIVMpQNVQYL2ygrLVuvZtXwQxPMuyoeLJNonFZaN0P7VGX415W3ohyUG5M 6xf+7DfUTkh8Na7ZXAJ4PNm0F0aRvXNbhOrG05sYGt9+YWdIo7R5gZqsi+t/6GKUeXyC Oeb76tnc+aYpwYMAIMvkwq0Hzhw+N8feDWJazlWbWKBR7X+I75M/SLIyPXtiDlgwjWNx CD6g== X-Gm-Message-State: AOAM5301iYisJQbS9BmE/FIf6q9m8b6Ir+ytvEgLKDI5dl59jKei6YWe fWBcbtYgT/lheV1yIZ7LlLJ8kGesMX4= X-Google-Smtp-Source: ABdhPJyEq157jMc8gJoHJK1BT/5iKGUvh7wp94eEpbkaSbqCfofHG8xm57p22fwgevIxb3KF1+WM2Q== X-Received: by 2002:aa7:8a88:0:b029:19d:8f05:b7a6 with SMTP id a8-20020aa78a880000b029019d8f05b7a6mr9980534pfc.39.1607210659173; Sat, 05 Dec 2020 15:24:19 -0800 (PST) Received: from [192.168.0.109] (c-24-130-62-181.hsd1.ca.comcast.net. [24.130.62.181]) by smtp.gmail.com with ESMTPSA id t22sm14990994pja.1.2020.12.05.15.24.18 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 05 Dec 2020 15:24:18 -0800 (PST) To: Michael Thomas , John Levine , dmarc@ietf.org References: <20201205231059.2BA23290EDCD@ary.qy> From: Dave Crocker Message-ID: Date: Sat, 5 Dec 2020 15:24:17 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] ARC vs reject X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 05 Dec 2020 23:24:21 -0000 On 12/5/2020 3:15 PM, Michael Thomas wrote: > Can you keep your contempt for me off this list? This is not even > responsive to what I wrote, and is nothing more than an ad hominem. Wow. It wasn't an ad hominem.  His response followed the exact form that was established in your note, in the way the requirement/expectation was specified. If you didn't want that form used, don't use it. In any event... There is a fundamental flaw in the publisher of a dmarc record thinking they have any rights or expectations about how a receiver will choose to handle a dmarc failure.  It's fine for the publisher to offer their own assessment of what the failure means to them.  It is not fine for the publisher to pretend to tell the receiver what to do about it. Even having a publisher's assessment be cast as 'advice' sets up the false expectation that the receiver should believe and care about that assessment.  Some might.  Others don't.  Talking about a receiver 'overriding' DMARC policy exemplifies this false and inappropriate expectation. d/ -- Dave Crocker dcrocker@gmail.com 408.329.0791 Volunteer, Silicon Valley Chapter American Red Cross dave.crocker2@redcross.org From nobody Sat Dec 5 15:37: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 ADB113A0E18 for ; Sat, 5 Dec 2020 15:37:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.652 X-Spam-Level: X-Spam-Status: No, score=-1.652 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mtcc-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h-W5RKmmQ5lc for ; Sat, 5 Dec 2020 15:37:14 -0800 (PST) Received: from mail-pg1-x530.google.com (mail-pg1-x530.google.com [IPv6:2607:f8b0:4864:20::530]) (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 0B6203A0D3C for ; Sat, 5 Dec 2020 15:37:13 -0800 (PST) Received: by mail-pg1-x530.google.com with SMTP id o4so5933109pgj.0 for ; Sat, 05 Dec 2020 15:37:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mtcc-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=go6cCTG6erkdl//wZen3Hrw53Wv5wfBTFuh6C8c4na8=; b=qSq/93WBYh+0Xp42YNPEZmUKm2cas6q+ePlR0uubhnTX02mP+1hiKg1ut/MjnCkbrD kMEtbU/WtCrvEJVlVjmrwUBzdMxP4vgOIB/Q3KcD7ggBkXJ4Ung+XWPnQagMEQf6H2m4 uqqSqAN1HG7nxh+LwFhT71+foAX8OhW8u5guAce/7/LjcAJ6lfkdvAXqkPW8yD0fltn2 SZ3D4AOeJ+ZDXqV2PW3eWpVegOuJz/1CS5sb34PuC03nS1ZLAod7zPtC+iEot2i2a9Tp oxnLob3Cp5rlwASobdnEy2D1NHDPvqgPJCh18B26htrSq1l6jNkYuNzdBF04w0xIx/i1 pV9Q== 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=go6cCTG6erkdl//wZen3Hrw53Wv5wfBTFuh6C8c4na8=; b=rpgUXBWig6KSs3fbL0eDYespuT8Za+PgnRMZpdpUd+0QWncNDd2Q+99g1QfEjYfIMp AU7z9ovh9h1PVniPOxyEMFgpvnj5kSj4u1v4QkCT9qvncaJ2iK8nnOUiaPZV0s9qc+oR BDSg9amjjj16mauevYD+pcDXgZ6wtyRmaEDcnOImvHmSrJFCOgFTZDfvHWHYE0VGiEbv zvSsyJLA7AlbLeM/D62bi3nFbe/JT7RFFJT11hpRjxnGhs+0e0DwZRm0xy5vM/gD7jZb dsG5bD4QJFnayrgmraXaTqDYcIg2j1UGAsINRI/McCWTcNbu6nRqN1kFwchoHlk2nh6u 20zg== X-Gm-Message-State: AOAM532sI8XSgjw7oSuOZDZyY2KT4uAKQdwZVIV7crQPG8sC0CvtxNCs yXF9If4xAFqqMVEHrbJKoyOw4i5l3t3R3w== X-Google-Smtp-Source: ABdhPJysE4oOZWhb7ZfxE3saTbQXnEQi3zydkUx+gOGyz5N/med7G8SqNqZpym4AR6Nd1A+hev9OrA== X-Received: by 2002:a62:2683:0:b029:19a:9594:1abe with SMTP id m125-20020a6226830000b029019a95941abemr10284032pfm.19.1607211432720; Sat, 05 Dec 2020 15:37:12 -0800 (PST) Received: from mike-mac.lan (107-182-42-33.volcanocom.com. [107.182.42.33]) by smtp.gmail.com with ESMTPSA id r4sm8396152pgs.54.2020.12.05.15.37.11 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 05 Dec 2020 15:37:12 -0800 (PST) To: Dave Crocker , John Levine , dmarc@ietf.org References: <20201205231059.2BA23290EDCD@ary.qy> From: Michael Thomas Message-ID: <7ae42764-176d-11a8-e084-b10b6f676944@mtcc.com> Date: Sat, 5 Dec 2020 15:37:10 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.5.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] ARC vs reject X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 05 Dec 2020 23:37:16 -0000 On 12/5/20 3:24 PM, Dave Crocker wrote: > On 12/5/2020 3:15 PM, Michael Thomas wrote: >> Can you keep your contempt for me off this list? This is not even >> responsive to what I wrote, and is nothing more than an ad hominem. > > > Wow. It wasn't an ad hominem. "You can say, no I am smarter than those guys and I REALLY REALLY mean it, but see 2) above." This is really not about questioning my intelligence. eye roll. If I said the same thing to you, you'd be screaming bloody murder to the chairs to try to get me banned again. > > There is a fundamental flaw in the publisher of a dmarc record > thinking they have any rights or expectations about how a receiver > will choose to handle a dmarc failure.  It's fine for the publisher to > offer their own assessment of what the failure means to them.  It is > not fine for the publisher to pretend to tell the receiver what to do > about it. > > Even having a publisher's assessment be cast as 'advice' sets up the > false expectation that the receiver should believe and care about that > assessment.  Some might.  Others don't.  Talking about a receiver > 'overriding' DMARC policy exemplifies this false and inappropriate > expectation. > If the publisher of the DMARC record cannot accurately state its desires/policy, that is a deficiency in the protocol. Reject means I want you to reject it. It doesn't carve out exceptions. ARC is trying to carve out exceptions. If it wants an exception, the originating domain should have a say in whether it desires the receiving domain to carve out an exception one way or the other. Mike From nobody Sat Dec 5 15:49: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 434C33A0E91 for ; Sat, 5 Dec 2020 15:49:34 -0800 (PST) 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 nYR8FRCMUWSo for ; Sat, 5 Dec 2020 15:49:32 -0800 (PST) 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 709BA3A0E90 for ; Sat, 5 Dec 2020 15:49:32 -0800 (PST) Received: by mail-oi1-x233.google.com with SMTP id s75so7884676oih.1 for ; Sat, 05 Dec 2020 15:49:32 -0800 (PST) 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=Kc3BnJaxUlJtCiKTYaVuTyxt1U2tSWt/jrNiN1Pmm34=; b=qmDgz5BJzKhUEYXIr0S/kPyDvsstW+u8r2UKru0BiJxrASQdhOOk1OHYrYWjMTeA/m AFYW4Uf1BcBbmXd0bls5ZUVkWZYCNv3/6jgdU6uMbYl1xXawfmWtzfduNkvGvDKzmoyw LwIWA9ahM/pmaqNr/GDkcHuouQpd5IsQS1LR3AQPivEDyVATEioSw5m+OoUzNMUKEJeu dwVS0o7Ejlp3OJ04zsGscdHVXgDrQ/QO8Y4YYt1ndpTtIj7qtMf7RN45BKogztHWIEQK XpKpg1lB+f/6AAJP1SpxWMtUsSF5ro2XXLvz4Nim11IqVGXqP/MlHi2P6s9fald109iG xQiw== 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=Kc3BnJaxUlJtCiKTYaVuTyxt1U2tSWt/jrNiN1Pmm34=; b=NEuR76XvXHh4y9flbrpYOosqaeoVeARZ40LJPlGAgmrN9jTEMoaQv4LdTltE03isLs ToymTvaX5IiuajnAFsrw3GP4dAeVzrCipphW7jQ2FA+xKZLxIE8YcobhiswgloA5OeR6 QLHmvmhfj890X6nLyjgiXfAtm89Bf20Snv+PKjhKbdToJpNHskAcDYVWnOHknmhGkHqQ N7kNNcNCHCbWFgElr1AohPJmLgwrHqr0Xp/GXhHo4cwfkJOTylrF3c//XAuGbsGLB3uk iN4Ul3kFJt18PeZMU301luT9KvTfWIT0Ak98Uhe0TlII+5bATQEJZWrAC3w1z0oVF265 DJ1g== X-Gm-Message-State: AOAM532tAn61pzCMlLkUCX17ev4cMb53UCYII3hpoaoHAhIflhl3N2Y+ tAXmF8BaRUWIPtIKC9DrIIAa/uMpKQXcldbFSjc= X-Google-Smtp-Source: ABdhPJx4DhV12h58AUjeqXDdIpkwAqicHxhHF9i890IreYlqqB6cgbOw2CrbOM/r53a2bqpIRf7r/Yki2iys0PZ8MqM= X-Received: by 2002:aca:c3c6:: with SMTP id t189mr7660818oif.21.1607212171582; Sat, 05 Dec 2020 15:49:31 -0800 (PST) MIME-Version: 1.0 References: <20201205231059.2BA23290EDCD@ary.qy> In-Reply-To: From: Tim Wicinski Date: Sat, 5 Dec 2020 18:49:20 -0500 Message-ID: To: Michael Thomas Cc: John Levine , IETF DMARC WG Content-Type: multipart/alternative; boundary="00000000000090df7505b5c03efa" Archived-At: Subject: Re: [dmarc-ietf] ARC vs reject X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 05 Dec 2020 23:49:34 -0000 --00000000000090df7505b5c03efa Content-Type: text/plain; charset="UTF-8" Michael I don't see john's comments as ad hominem. He's describing how his mail system interprets mail flow. But I do think a lot of this discussion is getting into very esoteric cases. I'd suggest trying to put your thoughts into a draft we can sit and chew on. Tim On Sat, Dec 5, 2020 at 6:16 PM Michael Thomas wrote: > > On 12/5/20 3:10 PM, John Levine wrote: > > In article you write: > >> If ARC is advocating for a bypass of p=reject that introduces a new > >> state. If my policy is reject, I want you to reject the mail. If I want > >> you to reject the mail unless you think it has come from an acceptable > >> place with receipts, then you need a new policy tag like > >> reject-except-valid-arc. > > Other people will have to speak for themselves but on my system > > > > a) I don't believe you. > > > > 2) I don't care. > > > > I think you will find this reaction pretty common. > > > > I see lots of mail going through my system like the stuff I described > > for the town clerk. It is obvious who it is intended for, the only way > > to deliver it to that recipient is to forward it, and if the DMARC > > policy says not to do that, the policy is wrong. I don't even need ARC > > for that, although ARC can be useful for mail that takes indirect > > routes for the mailing lists they subscribe to. > > > > You can say, no I am smarter than those guys and I REALLY REALLY mean > > it, but see 2) above. > > > > Can you keep your contempt for me off this list? This is not even > responsive to what I wrote, and is nothing more than an ad hominem. > > And your anecdotal evidence drawn from a tiny system is very suspect. > > Mike > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > --00000000000090df7505b5c03efa Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Michael

I don't see john's comments as=C2=A0ad hominem.=C2=A0 He's de= scribing how his mail system=C2=A0interprets=C2=A0mail flow.=C2=A0

But I do think a lot of this discussion is getting into very esoteric=C2= =A0cases.=C2=A0=C2=A0
<= font face=3D"monospace">I'd suggest trying=C2=A0to put your thoughts into a draft we can sit=C2=A0and= chew on.

Tim


On Sat, Dec 5, 2020 at 6:16 PM Michael Thomas <mike@mtcc.com> wrote:

On 12/5/20 3:10 PM, John Levine wrote:
> In article <dd59f2f3-b17e-6c2b-f756-7dcad2702fd9@mtcc.com> you write:
>> If ARC is advocating for a bypass of p=3Dreject that introduces a = new
>> state. If my policy is reject, I want you to reject the mail. If I= want
>> you to reject the mail unless you think it has come from an accept= able
>> place with receipts, then you need a new policy tag like
>> reject-except-valid-arc.
> Other people will have to speak for themselves but on my system
>
> a) I don't believe you.
>
> 2) I don't care.
>
> I think you will find this reaction pretty common.
>
> I see lots of mail going through my system like the stuff I described<= br> > for the town clerk. It is obvious who it is intended for, the only way=
> to deliver it to that recipient is to forward it, and if the DMARC
> policy says not to do that, the policy is wrong. I don't even need= ARC
> for that, although ARC can be useful for mail that takes indirect
> routes for the mailing lists they subscribe to.
>
> You can say, no I am smarter than those guys and I REALLY REALLY mean<= br> > it, but see 2) above.
>

Can you keep your contempt for me off this list? This is not even
responsive to what I wrote, and is nothing more than an ad hominem.

And=C2=A0 your anecdotal evidence drawn from a tiny system is very suspect.=

Mike

_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
--00000000000090df7505b5c03efa-- From nobody Sat Dec 5 15:59: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 047993A0E95 for ; Sat, 5 Dec 2020 15:59:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.65 X-Spam-Level: X-Spam-Status: No, score=-1.65 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, 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=mtcc-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RsvhVJivcne6 for ; Sat, 5 Dec 2020 15:59:20 -0800 (PST) Received: from mail-pj1-x1034.google.com (mail-pj1-x1034.google.com [IPv6:2607:f8b0:4864:20::1034]) (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 3F3583A0E96 for ; Sat, 5 Dec 2020 15:59:20 -0800 (PST) Received: by mail-pj1-x1034.google.com with SMTP id l23so5309873pjg.1 for ; Sat, 05 Dec 2020 15:59:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mtcc-com.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=/DvoNnxzYQ7+eaehvN09oJf9JgI279tjNyV13c5Us9U=; b=pyOhAVec2eOkbYNX/99Z5WMXaXNBBrJKDWL+MSNKjfFetBAOPMVGAO8n5q4h1EOD7J zxveHROol1diGc+lMhr7xto3GOhongW/FpGBFFS5V+mc5NcyfgjrZs/yznrXQIBAarBZ fKTfl3GAjO7jscIqfEU4qET27aaXiGA1KWGfjfM5+Jb8o3i/Nd4uIf+/IXNApJSWmBrM kXe3RJPpwg1vmEz6/5e/lapId5Z5bY8Mui7Rj7T4FgLwvxydygZVo7u1PCXIkUJYesrP uTn+9oqFdLZ3PJttN7ULx2oEpjpkMqVsoEZSReSL/oJ51qKdKxH7nXDFHAdYUNJe8xjA 20vQ== 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=/DvoNnxzYQ7+eaehvN09oJf9JgI279tjNyV13c5Us9U=; b=rmTbr/9fuX+hQTD2siRppM6fKeDEG1i8LJ4ZGoZAcNcYL2GpNRZSlJWKM/lfkDjB1T DsA42uWj40EUXscIdl78gZvMWqiW5k+ui0k3UkQuDGlJdNO4D+DuoQPU0VN3b75Yxg+r W8ubAQ9Ou1f0J44nLzSZWyTTylqQfcgphvbw/GYW+Ype5Hq67Z7CWmt5c159KFRx2Lqy JUMG1xQhWG7zjfG7E2PyNEBHLSMHvL3S4lrEs+zPQkh8Ka/kf0OLz0wuWWMlJSZBQQud mpqtEkrpAPlUU6QdkJOScGXAjGWJ8ua44etfBxVNFl++erun2Tx70+d84+YT9O6H+gJ8 mQXw== X-Gm-Message-State: AOAM530/Qcse6wgJluz4ZPdDj8eL+nCuc7IcHpxMMT6YJE9djORhzJ2U D4dh3cFGei8k2z7iak2ap3KpwNbAIwoVpw== X-Google-Smtp-Source: ABdhPJx0ZDc8DCnBgIl1YA1x09yA5UxQ7ZvmtGxwPWEmTe6KF67bFAJBJvVwV1gLjcrT5UC6Qdte9g== X-Received: by 2002:a17:902:b688:b029:d6:ad52:ffab with SMTP id c8-20020a170902b688b02900d6ad52ffabmr9920833pls.61.1607212759209; Sat, 05 Dec 2020 15:59:19 -0800 (PST) Received: from mike-mac.lan (107-182-42-33.volcanocom.com. [107.182.42.33]) by smtp.gmail.com with ESMTPSA id h12sm8106805pgf.49.2020.12.05.15.59.17 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 05 Dec 2020 15:59:18 -0800 (PST) To: Tim Wicinski Cc: John Levine , IETF DMARC WG References: <20201205231059.2BA23290EDCD@ary.qy> From: Michael Thomas Message-ID: Date: Sat, 5 Dec 2020 15:59:16 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------B5B0290A253484A6D41AD752" Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] ARC vs reject X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 05 Dec 2020 23:59:22 -0000 This is a multi-part message in MIME format. --------------B5B0290A253484A6D41AD752 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 12/5/20 3:49 PM, Tim Wicinski wrote: > Michael > > I don't see john's comments as ad hominem.  He's describing how his > mail system interprets mail flow. > > But I do think a lot of this discussion is getting into very > esoteric cases. > I'd suggest trying to put your thoughts into a draft we can sit and > chew on. Wow, you don't see the last line as questioning my intelligence? The two of them have been tag teaming me to get me thrown off of here since I returned just like they did on the DKIM list which I finally left because it wasn't worth their nastiness. I'll probably do the same here since the chairs seem to not care about their continuing hostility, but I will always have the fact that myself and two others created and wrote DKIM well before IETF came into the picture and the politics and credit seeking personalities it brings. Mike > > Tim > > > On Sat, Dec 5, 2020 at 6:16 PM Michael Thomas > wrote: > > > On 12/5/20 3:10 PM, John Levine wrote: > > In article > you write: > >> If ARC is advocating for a bypass of p=reject that introduces a new > >> state. If my policy is reject, I want you to reject the mail. > If I want > >> you to reject the mail unless you think it has come from an > acceptable > >> place with receipts, then you need a new policy tag like > >> reject-except-valid-arc. > > Other people will have to speak for themselves but on my system > > > > a) I don't believe you. > > > > 2) I don't care. > > > > I think you will find this reaction pretty common. > > > > I see lots of mail going through my system like the stuff I > described > > for the town clerk. It is obvious who it is intended for, the > only way > > to deliver it to that recipient is to forward it, and if the DMARC > > policy says not to do that, the policy is wrong. I don't even > need ARC > > for that, although ARC can be useful for mail that takes indirect > > routes for the mailing lists they subscribe to. > > > > You can say, no I am smarter than those guys and I REALLY REALLY > mean > > it, but see 2) above. > > > > Can you keep your contempt for me off this list? This is not even > responsive to what I wrote, and is nothing more than an ad hominem. > > And  your anecdotal evidence drawn from a tiny system is very suspect. > > Mike > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > > --------------B5B0290A253484A6D41AD752 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit


On 12/5/20 3:49 PM, Tim Wicinski wrote:
Michael

I don't see john's comments as ad hominem.  He's describing how his mail system interprets mail flow. 

But I do think a lot of this discussion is getting into very esoteric cases.  
I'd suggest trying to put your thoughts into a draft we can sit and chew on.

Wow, you don't see the last line as questioning my intelligence? The two of them have been tag teaming me to get me thrown off of here since I returned just like they did on the DKIM list which I finally left because it wasn't worth their nastiness. I'll probably do the same here since the chairs seem to not care about their continuing hostility, but I will always have the fact that myself and two others created and wrote DKIM well before IETF came into the picture and the politics and credit seeking personalities it brings.

Mike



Tim


On Sat, Dec 5, 2020 at 6:16 PM Michael Thomas <mike@mtcc.com> wrote:

On 12/5/20 3:10 PM, John Levine wrote:
> In article <dd59f2f3-b17e-6c2b-f756-7dcad2702fd9@mtcc.com> you write:
>> If ARC is advocating for a bypass of p=reject that introduces a new
>> state. If my policy is reject, I want you to reject the mail. If I want
>> you to reject the mail unless you think it has come from an acceptable
>> place with receipts, then you need a new policy tag like
>> reject-except-valid-arc.
> Other people will have to speak for themselves but on my system
>
> a) I don't believe you.
>
> 2) I don't care.
>
> I think you will find this reaction pretty common.
>
> I see lots of mail going through my system like the stuff I described
> for the town clerk. It is obvious who it is intended for, the only way
> to deliver it to that recipient is to forward it, and if the DMARC
> policy says not to do that, the policy is wrong. I don't even need ARC
> for that, although ARC can be useful for mail that takes indirect
> routes for the mailing lists they subscribe to.
>
> You can say, no I am smarter than those guys and I REALLY REALLY mean
> it, but see 2) above.
>

Can you keep your contempt for me off this list? This is not even
responsive to what I wrote, and is nothing more than an ad hominem.

And  your anecdotal evidence drawn from a tiny system is very suspect.

Mike

_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
--------------B5B0290A253484A6D41AD752-- From nobody Sat Dec 5 16:21: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 DB8AD3A0408 for ; Sat, 5 Dec 2020 16:21:26 -0800 (PST) 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 I6I-l6BHTkOe for ; Sat, 5 Dec 2020 16:21:25 -0800 (PST) Received: from mail-pj1-x1041.google.com (mail-pj1-x1041.google.com [IPv6:2607:f8b0:4864:20::1041]) (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 C06973A03F4 for ; Sat, 5 Dec 2020 16:21:25 -0800 (PST) Received: by mail-pj1-x1041.google.com with SMTP id b5so1437962pjl.0 for ; Sat, 05 Dec 2020 16:21:25 -0800 (PST) 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=T8p70SimSAodeJTQJFFz1/ssRZ7e2Edr5jm0nTN9blc=; b=RLUSvE8QYd8+Dh73NBeLDPOsqXiGIZeyX/kOaWTuPy2+Iw7H0oYFbm14IDrUXvl+rb wVPF+bXrneDIJ7f1pX0QUa0gUZ8v2ZRoYamtnMnzbpRTfnvh+fZgw3gWRhjQ7FK0BdmI lLcI0valUl3B/y0h/HLerFzbd2mriIIXfd2rfyj+qdzATP6ln56j7WbA0nnb0ifahWGu AiSZlXRIHBUHLmR1McDJ7JulyXhl2uSvL9ZKU+JxkOEld7ufEVHVgCvuY+ZcX2j4eXxj PL1rot3nzIPhXPV0HrYR8xQDPjdupvyJVkRrfFhJoA1pCAUSmAk4gYUD5nU3y5ZmUsHs HRJw== 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=T8p70SimSAodeJTQJFFz1/ssRZ7e2Edr5jm0nTN9blc=; b=hDalRoqJaPhxudvD2+8ELB1s4UTbrs5PhbqKfPVhkZ53AbhLfIviI+U0hKjrsoY1yl qedN7DPbJ7w8vZvxozJXLji/Ti80zXr7m9ACvfuFQdk0hhNrDDnUeWKeVq0cQrTlNayK zqxBi7hPuMcG/EHyV1bMzjVFRjI4sGPIS9ST8oeQR2AexqvEbS5TUAqqvtDPIa0vhCbA 74ZHdQxnakUcbNTt44qVa2OkiHdnU34N9X3HRm+vdRyhiCvfMW/CxUBuMZSjggoXnSpJ 4W802l6/F62tir64rNg3zywvxe0BK6gAw39tzg6EM8Opm8X/WSh7W4zV6lpzWg+KAplt jPzg== X-Gm-Message-State: AOAM5321VhYOTSjy1SZ+z3eJ8Iu7+6esLEZf5cVjZhliARG0D4FkIpVc 4pK88MZhV1Bm2Tqn70vAysJ2wI6FiPA= X-Google-Smtp-Source: ABdhPJz6JJQOznemjyDeiypacU4WcxtEH47GlQcSkFspTxH39jOSIDDJJfBSySEqpMCK8PEdd64ptg== X-Received: by 2002:a17:90a:6749:: with SMTP id c9mr10373474pjm.129.1607214084993; Sat, 05 Dec 2020 16:21:24 -0800 (PST) Received: from [192.168.0.109] (c-24-130-62-181.hsd1.ca.comcast.net. [24.130.62.181]) by smtp.gmail.com with ESMTPSA id g14sm9370090pfo.198.2020.12.05.16.21.24 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 05 Dec 2020 16:21:24 -0800 (PST) To: Michael Thomas , John Levine , dmarc@ietf.org References: <20201205231059.2BA23290EDCD@ary.qy> <7ae42764-176d-11a8-e084-b10b6f676944@mtcc.com> From: Dave Crocker Message-ID: Date: Sat, 5 Dec 2020 16:21:23 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.5.1 MIME-Version: 1.0 In-Reply-To: <7ae42764-176d-11a8-e084-b10b6f676944@mtcc.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] ARC vs reject X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 06 Dec 2020 00:21:27 -0000 On 12/5/2020 3:37 PM, Michael Thomas wrote: > On 12/5/20 3:24 PM, Dave Crocker wrote: >> On 12/5/2020 3:15 PM, Michael Thomas wrote: >>> Can you keep your contempt for me off this list? This is not even >>> responsive to what I wrote, and is nothing more than an ad hominem. >> >> Wow. It wasn't an ad hominem. > "You can say, no I am smarter than those guys and I REALLY REALLY mean > it, but see 2) above." > > This is really not about questioning my intelligence. eye roll. If I > said the same thing to you, you'd be screaming bloody murder to the > chairs to try to get me banned again. Note that what you have just done is, in fact, an ad hominem and arguably does violate IETF participation rules. Again, the response you are objecting two exactly followed the linguistic form of the setup you offered.  As such, the response was not directly at you, the author of the posting, but at the hypothetical person you formulated. > If the publisher of the DMARC record cannot accurately state its > desires/policy, that is a deficiency in the protocol. Reject means I > want you to reject it. It doesn't carve out exceptions. ARC is trying > to carve out exceptions. If it wants an exception, the originating > domain should have a say in whether it desires the receiving domain to > carve out an exception one way or the other. The domain owner might want all sorts of unreasonable things. Having a way to let the domain owner publish demands that are widely ignored indicates a seriously flawed semantic model. And that is, indeed, the current reality for DMARC. d/ -- Dave Crocker dcrocker@gmail.com 408.329.0791 Volunteer, Silicon Valley Chapter American Red Cross dave.crocker2@redcross.org From nobody Sat Dec 5 16:42: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 440263A074E for ; Sat, 5 Dec 2020 16:42:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.652 X-Spam-Level: X-Spam-Status: No, score=-1.652 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mtcc-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yeLR5CgX0_PE for ; Sat, 5 Dec 2020 16:42:04 -0800 (PST) Received: from mail-pj1-x1030.google.com (mail-pj1-x1030.google.com [IPv6:2607:f8b0:4864:20::1030]) (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 D95F73A0644 for ; Sat, 5 Dec 2020 16:42:00 -0800 (PST) Received: by mail-pj1-x1030.google.com with SMTP id lb18so2733682pjb.5 for ; Sat, 05 Dec 2020 16:42:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mtcc-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=pMCXJ16nlBFokIixnbPZc/ZMrG8Y1tAnlZigLxIRNDY=; b=K/oewfmCTXhAvDAjX5yCXuo/H3lSdfcJAgm78/1ihCCwEyHWIUqwqdAPRumdy90y/F fRH+FccugfJcxuVCMSDQxeTqCLA1KmdZyrNdWsuYVaJUIGqBqLwIxyyfDcG9TjgNRY5X /gOKc8tjJ1E0Pg05bIUa1pxdgoFOgQtwHeiurQP9yTlmrJxXCCvqc393vIJWTWAKtobO 6/xxZJeinW+lseKEOff2ccPrPUpQTsMRv1mutjwRuILOTA2lQpn9WtRvcUjcRbeMcTr0 Uu1XLSYgKWGF4kcaA8WLGl3EA2ca+0EnhDajAEW2TqN4YFgQ4QZUm/qyD95vrA6oKzfj 1xOg== 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=pMCXJ16nlBFokIixnbPZc/ZMrG8Y1tAnlZigLxIRNDY=; b=j6LazKiBeKipUnGJsHZao/L8Ya0vPPbK0NTA+4FEU9pOxVfw8ndUEujgnp8ba0t96N WdkAChIvRzQjDLpx/GA5V+QGpOPHYShSoFqemRzrJB8ho08p2r0zoch+LAbYqArU/Lv2 kUBYTdtypFtnCVexYgxY2DOOP3fzr9nyi4DkyBqzGh+HYZ/oOhMdMMDrdPCGqr7E9728 O9TrO9t8YU6j4WMenRyEaSH/u5VpPBFeGppByKd29VlVBZjpurKpczjYk1saaLORihjl xyF93mrZsaf2fvFgkQLUvYfWLfBcHeu8rGWHWUnIc7Yi+GNVxQPfoI3nmnnLyOroEgh5 c8MA== X-Gm-Message-State: AOAM531M/ye7erXzZNaq/o0kSDQztPjPw64COPAJt4WVc28BfpJ5/oTd 4eTuHLt7OdoCXXNDe3D9YXEk4DHx8W8r/g== X-Google-Smtp-Source: ABdhPJx3CzRXUGJfEhd/RKYM6G083BidvP7ykOdY3uPDyN0pXV6fF4Vi4FZfHXwmOzi8gKEnxWnsnA== X-Received: by 2002:a17:90b:388:: with SMTP id ga8mr774319pjb.108.1607215319632; Sat, 05 Dec 2020 16:41:59 -0800 (PST) Received: from mike-mac.lan (107-182-42-33.volcanocom.com. [107.182.42.33]) by smtp.gmail.com with ESMTPSA id p21sm9149319pfn.87.2020.12.05.16.41.57 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 05 Dec 2020 16:41:58 -0800 (PST) To: Dave Crocker , John Levine , dmarc@ietf.org References: <20201205231059.2BA23290EDCD@ary.qy> <7ae42764-176d-11a8-e084-b10b6f676944@mtcc.com> From: Michael Thomas Message-ID: <8142f18c-ac79-1f94-97d1-2704f0b4ceb6@mtcc.com> Date: Sat, 5 Dec 2020 16:41:57 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.5.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] ARC vs reject X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 06 Dec 2020 00:42:05 -0000 On 12/5/20 4:21 PM, Dave Crocker wrote: > On 12/5/2020 3:37 PM, Michael Thomas wrote: >> "You can say, no I am smarter than those guys and I REALLY REALLY >> mean it, but see 2) above." >> >> This is really not about questioning my intelligence. eye roll. If I >> said the same thing to you, you'd be screaming bloody murder to the >> chairs to try to get me banned again. > > Note that what you have just done is, in fact, an ad hominem and > arguably does violate IETF participation rules. How can me pointing out that you would call that an ad hominem, become ad hominem? This is the bizzarro world that caused me to leave the last time. > > Again, the response you are objecting two exactly followed the > linguistic form of the setup you offered.  As such, the response was > not directly at you, the author of the posting, but at the > hypothetical person you formulated. Oh yeah, I just missed the implied royal you in the reply directed at me from somebody who has a long history of antagonism to me including petty 5xx messages from direct mail to him. Whatever was I thinking in the Panglossian world we live in? > >> If the publisher of the DMARC record cannot accurately state its >> desires/policy, that is a deficiency in the protocol. Reject means I >> want you to reject it. It doesn't carve out exceptions. ARC is trying >> to carve out exceptions. If it wants an exception, the originating >> domain should have a say in whether it desires the receiving domain >> to carve out an exception one way or the other. > > The domain owner might want all sorts of unreasonable things. Having a > way to let the domain owner publish demands that are widely ignored > indicates a seriously flawed semantic model. And that is, indeed, the > current reality for DMARC. > You are fixated on what the receiver must or must not do. I never said anything about that. That is a strawman. I'm pointing out that ARC is trying to get two states out of reject where there only is one. It is certainly not unreasonable for my bank to say "please reject anything that is not by the letter of the law". I don't want somebody to figure out how to game all of this ARC stuff to phish me from my bank. That is far from unreasonable. But you can say, no I am smarter than those banks and I REALLY REALLY mean it, but I don't care. Mike From nobody Sat Dec 5 17:21: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 06F7D3A09FA for ; Sat, 5 Dec 2020 17:21:00 -0800 (PST) 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 uXBEPuLCVAtz for ; Sat, 5 Dec 2020 17:20:58 -0800 (PST) Received: from mail-vk1-xa30.google.com (mail-vk1-xa30.google.com [IPv6:2607:f8b0:4864:20::a30]) (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 C15603A09F9 for ; Sat, 5 Dec 2020 17:20:57 -0800 (PST) Received: by mail-vk1-xa30.google.com with SMTP id h133so1239547vka.6 for ; Sat, 05 Dec 2020 17:20:57 -0800 (PST) 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=sTCldYCUR6OiAFpVMPshM3j62nU4g9+76qhK65f+imk=; b=F9Yv0B13iUK0F1wOz/4p5dVYaGu34OQsHoGFWltkoY13LD01ukV6/FSHhrWChsTfdC 1PzkvwXa3Kuahx99muET07BwlnGS+E8iRG7S/0J5kqZlfRo/QnVvmGlVboTlvrYdM9Ec i7QG++A7rCr4y6LPbBrgfB1atzo3a+3wNqx1wB7Gj7UAXG/IYRc+zy1h122GWtr1oDnO BSpkCzpl3uQmcdbd6F85gx/UJKQmZdJpne/oTKg22Cr6mjvEXSid+XRhgHjk5Qf6CTOG /2/3yLZbBIaj/btACh6MVyjlG22kB6DJ6HUn4NINKnr0EKCm5QCjGwI1d8pcankp4jWu EwNA== 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=sTCldYCUR6OiAFpVMPshM3j62nU4g9+76qhK65f+imk=; b=AFUMjpXo6JWIIq/imbxXSmIrOxhLy1qu4bxe/RFcqknF2jn4t2vDl7902TxNRvY+/v 1sZqAxM2Jf0yOgDwBjiGulPa54jaLEM7S49tt9SmXKelcfDlNSsvQuIciM9Qp6dtQwqR 5aFGYZrq6CdXXuWy9xH2AxqqKuZF0Msi7EN9SkTZ6EsRYu4QQUDPkAJ8rUhAfAKf0xmZ 3YXURYnVgFyhzIFd4dTAXJB7mT/3Ke1stYCZ7e3MJKJqp/uZX47u5L1weUaDHRgSJjh7 LVnTFFk8OfOf+Ck1Tdu4wf4bV3a2ptNFC1CHFX0uqD8wzZ9t5VXRMDZFdjFRG6qjOQR5 Tpqg== X-Gm-Message-State: AOAM531SzE5rHyJ91fRwnF6Fac6eyB7Rb0D1ZrcTaQpo2vmXlwV8aKgA uYrt05vWoGZhcHtzmciqcau4BA0RNsp9faX3ieu+4hNL708= X-Google-Smtp-Source: ABdhPJyp0f0YOlV4JY/c/tdPevmpgoM4S+QGIrdEW7/KnePXwZ6Q6Obe5l/HLXZbmcQ5owN4+Nys6KQWJpHGkvJDRZk= X-Received: by 2002:a1f:2717:: with SMTP id n23mr9192287vkn.25.1607217656581; Sat, 05 Dec 2020 17:20:56 -0800 (PST) MIME-Version: 1.0 References: <20201205231059.2BA23290EDCD@ary.qy> <7ae42764-176d-11a8-e084-b10b6f676944@mtcc.com> <8142f18c-ac79-1f94-97d1-2704f0b4ceb6@mtcc.com> In-Reply-To: <8142f18c-ac79-1f94-97d1-2704f0b4ceb6@mtcc.com> From: Douglas Foster Date: Sat, 5 Dec 2020 20:20:47 -0500 Message-ID: To: dmarc@ietf.org Content-Type: multipart/alternative; boundary="0000000000007f511105b5c185f2" Archived-At: Subject: Re: [dmarc-ietf] ARC vs reject X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 06 Dec 2020 01:21:00 -0000 --0000000000007f511105b5c185f2 Content-Type: text/plain; charset="UTF-8" 1) Michael. you have belabored your questions about DKIM vs ARC rather too long. It is what it is. 2) On the issue of "Do Not Forward": It is certainly an available feature of postal mail, which the postal service enforces. Email has no central authority to reliable enforce such a policy. Just as importantly, no one should (and few businesses do) consider email to be an environment where sensitive information is transmitted. Any competent bank will send an email telling you to log into their website to obtain the sensitive information. I do not see a "Do Not Forward" policy as something that is useful or likely to be used. 3) On the issue of p=reject: You have been usefully pressing the question of what purpose lies behind the technology. In the case of DMARC, the purpose is to block spoofed messages. We know that mailing lists turn a legitimate message into a looks-like-spoof message. ARC is trying to fix the false spoof, which is a worthy goal. More precisely, it is trying to provide information to the recipient system so that the recipient system can determine that the message is forwarded but not spoofed. 4) On the future of ARC: The idea is harmless, but I do not see it achieving the list-industry goal of eliminating From rewrite. It actually reminds me of DKIM without DMARC - a technology looking for an algorithm to which it can contribute. Since nobody can articulate how a recipient uses ARC information to reach an expected conclusion, something important is still missing. As I wrote in my last post, I think it fails to provide enough information for a useful algorithm to be defined. Even if that can be solved, there are bigger problems. We have no algorithm for a list to know if a particular recipient uses ARC, or whether it will use the ARC information to draw the desired conclusion about list messages. Without those answers, the list is doomed to continue From rewrite even if when it would not be necessary. And much of this is about AOL in particular, and the currently available information suggests that AOL is not on board with ARC. 5) The work you and Alessandro have done with reverse transformation is more likely to produce a solution for the mailing lists. The lists will continue to do From rewrite, but reverse-transform recipients can validate the true source of the message and restore the From if desired. On Sat, Dec 5, 2020 at 7:42 PM Michael Thomas wrote: > > On 12/5/20 4:21 PM, Dave Crocker wrote: > > On 12/5/2020 3:37 PM, Michael Thomas wrote: > >> "You can say, no I am smarter than those guys and I REALLY REALLY > >> mean it, but see 2) above." > >> > >> This is really not about questioning my intelligence. eye roll. If I > >> said the same thing to you, you'd be screaming bloody murder to the > >> chairs to try to get me banned again. > > > > Note that what you have just done is, in fact, an ad hominem and > > arguably does violate IETF participation rules. > > How can me pointing out that you would call that an ad hominem, become > ad hominem? > > This is the bizzarro world that caused me to leave the last time. > > > > > Again, the response you are objecting two exactly followed the > > linguistic form of the setup you offered. As such, the response was > > not directly at you, the author of the posting, but at the > > hypothetical person you formulated. > > Oh yeah, I just missed the implied royal you in the reply directed at me > from somebody who has a long history of antagonism to me including petty > 5xx messages from direct mail to him. Whatever was I thinking in the > Panglossian world we live in? > > > > >> If the publisher of the DMARC record cannot accurately state its > >> desires/policy, that is a deficiency in the protocol. Reject means I > >> want you to reject it. It doesn't carve out exceptions. ARC is trying > >> to carve out exceptions. If it wants an exception, the originating > >> domain should have a say in whether it desires the receiving domain > >> to carve out an exception one way or the other. > > > > The domain owner might want all sorts of unreasonable things. Having a > > way to let the domain owner publish demands that are widely ignored > > indicates a seriously flawed semantic model. And that is, indeed, the > > current reality for DMARC. > > > You are fixated on what the receiver must or must not do. I never said > anything about that. That is a strawman. I'm pointing out that ARC is > trying to get two states out of reject where there only is one. It is > certainly not unreasonable for my bank to say "please reject anything > that is not by the letter of the law". I don't want somebody to figure > out how to game all of this ARC stuff to phish me from my bank. That is > far from unreasonable. > > But you can say, no I am smarter than those banks and I REALLY REALLY > mean it, but I don't care. > > Mike > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > --0000000000007f511105b5c185f2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
1) Michael. you have belabored your questions about D= KIM vs ARC rather too long.=C2=A0 =C2=A0 It is what it is.

2) On the issue of "Do Not Forward":=C2=A0 It is certain= ly an available feature of postal mail, which the postal service enforces.= =C2=A0 =C2=A0Email has no central authority to reliable enforce such a poli= cy.=C2=A0 =C2=A0Just as importantly, no one should (and few businesses do) = consider email to be an environment where sensitive information is transmit= ted.=C2=A0 =C2=A0Any competent bank will send an email telling you to log i= nto their website to obtain the sensitive information.=C2=A0 =C2=A0I do not= see a "Do Not Forward" policy as something that is useful or lik= ely to be used.

3) On the issue of p=3Dreject:=C2= =A0 =C2=A0 You have been usefully pressing the question of what purpose lie= s behind the technology.=C2=A0 =C2=A0 In the case of DMARC, the purpose is = to block spoofed messages.=C2=A0 =C2=A0 We know that mailing lists turn a l= egitimate message into a looks-like-spoof message.=C2=A0 =C2=A0ARC is tryin= g to fix the false spoof, which is a worthy goal.=C2=A0 =C2=A0More precisel= y, it is trying to provide information to the recipient system so that the = recipient system can determine that the message is forwarded but not spoofe= d.

4) On the future of ARC:=C2=A0 =C2=A0The idea i= s harmless, but I do not see it achieving=C2=A0the list-industry goal of el= iminating From rewrite.=C2=A0 It actually reminds me of DKIM without DMARC = - a technology looking for an algorithm to which it can contribute.=C2=A0 = =C2=A0 Since nobody can articulate how a recipient uses ARC information to = reach an expected conclusion, something important is still missing.=C2=A0 = =C2=A0 As I wrote in my last post, I think it fails to provide enough infor= mation for a useful algorithm to be defined.=C2=A0 =C2=A0 Even if that can = be solved, there=C2=A0are bigger problems.=C2=A0 =C2=A0We have no algorithm= for a list to know if a particular recipient uses ARC, or whether it will = use the ARC information to draw the desired conclusion about list messages.= =C2=A0 =C2=A0Without those answers, the=C2=A0list is doomed to continue Fro= m rewrite even if when=C2=A0it would not be necessary.=C2=A0 =C2=A0 And muc= h of this is about AOL in particular, and the currently available informati= on suggests that AOL is not on board with ARC.

5) = The work you and Alessandro have done with reverse transformation is more l= ikely to produce a solution for the mailing lists.=C2=A0 =C2=A0The lists wi= ll continue to do From rewrite, but reverse-transform recipients can valida= te the true source of the message and restore the From if desired.

On = Sat, Dec 5, 2020 at 7:42 PM Michael Thomas <mike@mtcc.com> wrote:

On 12/5/20 4:21 PM, Dave Crocker wrote:
> On 12/5/2020 3:37 PM, Michael Thomas wrote:
>> "You can say, no I am smarter than those guys and I REALLY RE= ALLY
>> mean it, but see 2) above."
>>
>> This is really not about questioning my intelligence. eye roll. If= I
>> said the same thing to you, you'd be screaming bloody murder t= o the
>> chairs to try to get me banned again.
>
> Note that what you have just done is, in fact, an ad hominem and
> arguably does violate IETF participation rules.

How can me pointing out that you would call that an ad hominem, become
ad hominem?

This is the bizzarro world that caused me to leave the last time.

>
> Again, the response you are objecting two exactly followed the
> linguistic form of the setup you offered.=C2=A0 As such, the response = was
> not directly at you, the author of the posting, but at the
> hypothetical person you formulated.

Oh yeah, I just missed the implied royal you in the reply directed at me from somebody who has a long history of antagonism to me including petty 5xx messages from direct mail to him. Whatever was I thinking in the
Panglossian world we live in?

>
>> If the publisher of the DMARC record cannot accurately state its <= br> >> desires/policy, that is a deficiency in the protocol. Reject means= I
>> want you to reject it. It doesn't carve out exceptions. ARC is= trying
>> to carve out exceptions. If it wants an exception, the originating=
>> domain should have a say in whether it desires the receiving domai= n
>> to carve out an exception one way or the other.
>
> The domain owner might want all sorts of unreasonable things. Having a=
> way to let the domain owner publish demands that are widely ignored > indicates a seriously flawed semantic model. And that is, indeed, the =
> current reality for DMARC.
>
You are fixated on what the receiver must or must not do. I never said
anything about that. That is a strawman. I'm pointing out that ARC is <= br> trying to get two states out of reject where there only is one. It is
certainly not unreasonable for my bank to say "please reject anything =
that is not by the letter of the law". I don't want somebody to fi= gure
out how to game all of this ARC stuff to phish me from my bank. That is far from unreasonable.

But you can say, no I am smarter than those banks and I REALLY REALLY
mean it, but I don't care.

Mike

_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
--0000000000007f511105b5c185f2-- From nobody Sat Dec 5 17:34: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 E9CEB3A03F1 for ; Sat, 5 Dec 2020 17:34:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.65 X-Spam-Level: X-Spam-Status: No, score=-1.65 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, 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=mtcc-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KWqLE0qq3dLo for ; Sat, 5 Dec 2020 17:34:48 -0800 (PST) Received: from mail-pj1-x102d.google.com (mail-pj1-x102d.google.com [IPv6:2607:f8b0:4864:20::102d]) (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 DBEC23A03EE for ; Sat, 5 Dec 2020 17:34:48 -0800 (PST) Received: by mail-pj1-x102d.google.com with SMTP id hk16so5367017pjb.4 for ; Sat, 05 Dec 2020 17:34:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mtcc-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=6535xBrRkvMZwKKwXJuTXQ5V/20MKcxG3jnfR9YsMcI=; b=lR/N9pf5j/adMPD6HV/gWYpbO4Yn64VvLbQiqQNT8Wg8PNeW0Aj3yzBW2oHWE0YFD7 62PbPX7TiWHiuagA44xHlcDtUzbodZ++GDCU7eeyK2MhFBIxwl9MRhlvLT8cc0+biRK1 1fPMD4xXgyeoZq4qtyEHoF1CX70GOBiMpjfFXoCyzkNvbu1q9GvdXcjmDQBeahz47kWQ hkpUoLFTmExcA+xx0nTngZxkXTNXYRO7Ji7MXC7KSEmt7Fb1bmS/X+z8gMg1xgP7Rr+K AESu6mfMNZyxAyHGJRppSi6Evctkw+OCfz4MoT8rl9tr9DvTbyIBQRe8S3n9TTKx7Bpt 9JFQ== 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=6535xBrRkvMZwKKwXJuTXQ5V/20MKcxG3jnfR9YsMcI=; b=VXeEsDhKuzHsUePajtP5/hMYQOyepJ1LDD8P9E047BcCz1jZ/4e/ZuZLuVWRR8Jp/v Bn+tAQEDFXlRwEiafmYj4s0psEUe7wcKJB7wUll3lQzZbEzFb80Osv8gnzlUIerjP/4w Szj/iG9H5f3pqbaUQtqd0KeTUjRHNstbOeOvdDN4rhYmG+DxQfc6sy0Oa++cU3jowSiH O+KHOP3s4xUK4U20ZaK1MCiSg0pVxtWMWgLcf0CBFeTCgRIIQZRlBeZXW+sYnku4a0VG +7JE/QCigEO3RZl9xwIGZR5/0N3J2wkzNUyFHpRiHLLYPC5LkQZrE+syLMycti2eysxC Mc5Q== X-Gm-Message-State: AOAM531FOoqYAwxzCgo/KqEihP2/hdxPtZvnTQT+qXtW6vvd4orxyahq Q8topOgHsuC6j1a5qtMVmzRXXIG+mstjRg== X-Google-Smtp-Source: ABdhPJwWMGCOo+4WIwsxy6kDzRxvO0uCpfcj7OI9PpDLcOaZd0wiR7PQpapWcXICKem5YnVE1xCrpg== X-Received: by 2002:a17:90a:8d17:: with SMTP id c23mr10753271pjo.192.1607218487617; Sat, 05 Dec 2020 17:34:47 -0800 (PST) Received: from mike-mac.lan (107-182-42-33.volcanocom.com. [107.182.42.33]) by smtp.gmail.com with ESMTPSA id e14sm7824539pgv.64.2020.12.05.17.34.46 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 05 Dec 2020 17:34:46 -0800 (PST) To: dmarc@ietf.org References: <20201205231059.2BA23290EDCD@ary.qy> <7ae42764-176d-11a8-e084-b10b6f676944@mtcc.com> <8142f18c-ac79-1f94-97d1-2704f0b4ceb6@mtcc.com> From: Michael Thomas Message-ID: <72d32b62-64fb-937a-dac5-6f4c5816f523@mtcc.com> Date: Sat, 5 Dec 2020 17:34:45 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------475835F9D0C3D551D804E88B" Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] ARC vs reject X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 06 Dec 2020 01:34:51 -0000 This is a multi-part message in MIME format. --------------475835F9D0C3D551D804E88B Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 12/5/20 5:20 PM, Douglas Foster wrote: > 1) Michael. you have belabored your questions about DKIM vs ARC rather > too long.    It is what it is. ARC is an experiment. Experiments require peer review. > > 2) On the issue of "Do Not Forward":  It is certainly an available > feature of postal mail, which the postal service enforces.   Email has > no central authority to reliable enforce such a policy.   Just as > importantly, no one should (and few businesses do) consider email to > be an environment where sensitive information is transmitted.   Any > competent bank will send an email telling you to log into their > website to obtain the sensitive information.   I do not see a "Do Not > Forward" policy as something that is useful or likely to be used. DKIM is a mechanism which allows you to be assured that the forwarding was done without altering. Since email is more like postcard than a letter in an envelope that is a good property. > > 3) On the issue of p=reject:    You have been usefully pressing the > question of what purpose lies behind the technology.    In the case of > DMARC, the purpose is to block spoofed messages.    We know that > mailing lists turn a legitimate message into a looks-like-spoof > message.   ARC is trying to fix the false spoof, which is a worthy > goal.   More precisely, it is trying to provide information to the > recipient system so that the recipient system can determine that the > message is forwarded but not spoofed. Yes, but my bank seriously does not want any "acceptable" transformations. There are no acceptable transformations. DMARC needs to provide for that use case (and, in fact, it does currently). ARC is setting up a situation where there is no way for my bank to say, "no way, never". > > 4) On the future of ARC:   The idea is harmless To the contrary security protocols often create unintended consequences. The are never "harmless" until proven so. An experiment is hardly confidence-inspiring that it has been fully vetted. > > 5) The work you and Alessandro have done with reverse transformation > is more likely to produce a solution for the mailing lists.   The > lists will continue to do From rewrite, but reverse-transform > recipients can validate the true source of the message and restore the > From if desired. I'm starting to get a little more serious about my quip that the MLM can insert a sed script in a header to unmangle the message since it knows what transforms it has done, unlike the receiving MTA trying to guess the common transformations. Mike > > On Sat, Dec 5, 2020 at 7:42 PM Michael Thomas > wrote: > > > On 12/5/20 4:21 PM, Dave Crocker wrote: > > On 12/5/2020 3:37 PM, Michael Thomas wrote: > >> "You can say, no I am smarter than those guys and I REALLY REALLY > >> mean it, but see 2) above." > >> > >> This is really not about questioning my intelligence. eye roll. > If I > >> said the same thing to you, you'd be screaming bloody murder to > the > >> chairs to try to get me banned again. > > > > Note that what you have just done is, in fact, an ad hominem and > > arguably does violate IETF participation rules. > > How can me pointing out that you would call that an ad hominem, > become > ad hominem? > > This is the bizzarro world that caused me to leave the last time. > > > > > Again, the response you are objecting two exactly followed the > > linguistic form of the setup you offered.  As such, the response > was > > not directly at you, the author of the posting, but at the > > hypothetical person you formulated. > > Oh yeah, I just missed the implied royal you in the reply directed > at me > from somebody who has a long history of antagonism to me including > petty > 5xx messages from direct mail to him. Whatever was I thinking in the > Panglossian world we live in? > > > > >> If the publisher of the DMARC record cannot accurately state its > >> desires/policy, that is a deficiency in the protocol. Reject > means I > >> want you to reject it. It doesn't carve out exceptions. ARC is > trying > >> to carve out exceptions. If it wants an exception, the originating > >> domain should have a say in whether it desires the receiving > domain > >> to carve out an exception one way or the other. > > > > The domain owner might want all sorts of unreasonable things. > Having a > > way to let the domain owner publish demands that are widely ignored > > indicates a seriously flawed semantic model. And that is, > indeed, the > > current reality for DMARC. > > > You are fixated on what the receiver must or must not do. I never > said > anything about that. That is a strawman. I'm pointing out that ARC is > trying to get two states out of reject where there only is one. It is > certainly not unreasonable for my bank to say "please reject anything > that is not by the letter of the law". I don't want somebody to > figure > out how to game all of this ARC stuff to phish me from my bank. > That is > far from unreasonable. > > But you can say, no I am smarter than those banks and I REALLY REALLY > mean it, but I don't care. > > Mike > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > > > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc --------------475835F9D0C3D551D804E88B Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit


On 12/5/20 5:20 PM, Douglas Foster wrote:
1) Michael. you have belabored your questions about DKIM vs ARC rather too long.    It is what it is.


ARC is an experiment. Experiments require peer review.


2) On the issue of "Do Not Forward":  It is certainly an available feature of postal mail, which the postal service enforces.   Email has no central authority to reliable enforce such a policy.   Just as importantly, no one should (and few businesses do) consider email to be an environment where sensitive information is transmitted.   Any competent bank will send an email telling you to log into their website to obtain the sensitive information.   I do not see a "Do Not Forward" policy as something that is useful or likely to be used.

DKIM is a mechanism which allows you to be assured that the forwarding was done without altering. Since email is more like postcard than a letter in an envelope that is a good property.



3) On the issue of p=reject:    You have been usefully pressing the question of what purpose lies behind the technology.    In the case of DMARC, the purpose is to block spoofed messages.    We know that mailing lists turn a legitimate message into a looks-like-spoof message.   ARC is trying to fix the false spoof, which is a worthy goal.   More precisely, it is trying to provide information to the recipient system so that the recipient system can determine that the message is forwarded but not spoofed.

Yes, but my bank seriously does not want any "acceptable" transformations. There are no acceptable transformations. DMARC needs to provide for that use case (and, in fact, it does currently). ARC is setting up a situation where there is no way for my bank to say, "no way, never".



4) On the future of ARC:   The idea is harmless
To the contrary security protocols often create unintended consequences. The are never "harmless" until proven so. An experiment is hardly confidence-inspiring that it has been fully vetted.

5) The work you and Alessandro have done with reverse transformation is more likely to produce a solution for the mailing lists.   The lists will continue to do From rewrite, but reverse-transform recipients can validate the true source of the message and restore the From if desired.

I'm starting to get a little more serious about my quip that the MLM can insert a sed script in a header to unmangle the message since it knows what transforms it has done, unlike the receiving MTA trying to guess the common transformations.

Mike



On Sat, Dec 5, 2020 at 7:42 PM Michael Thomas <mike@mtcc.com> wrote:

On 12/5/20 4:21 PM, Dave Crocker wrote:
> On 12/5/2020 3:37 PM, Michael Thomas wrote:
>> "You can say, no I am smarter than those guys and I REALLY REALLY
>> mean it, but see 2) above."
>>
>> This is really not about questioning my intelligence. eye roll. If I
>> said the same thing to you, you'd be screaming bloody murder to the
>> chairs to try to get me banned again.
>
> Note that what you have just done is, in fact, an ad hominem and
> arguably does violate IETF participation rules.

How can me pointing out that you would call that an ad hominem, become
ad hominem?

This is the bizzarro world that caused me to leave the last time.

>
> Again, the response you are objecting two exactly followed the
> linguistic form of the setup you offered.  As such, the response was
> not directly at you, the author of the posting, but at the
> hypothetical person you formulated.

Oh yeah, I just missed the implied royal you in the reply directed at me
from somebody who has a long history of antagonism to me including petty
5xx messages from direct mail to him. Whatever was I thinking in the
Panglossian world we live in?

>
>> If the publisher of the DMARC record cannot accurately state its
>> desires/policy, that is a deficiency in the protocol. Reject means I
>> want you to reject it. It doesn't carve out exceptions. ARC is trying
>> to carve out exceptions. If it wants an exception, the originating
>> domain should have a say in whether it desires the receiving domain
>> to carve out an exception one way or the other.
>
> The domain owner might want all sorts of unreasonable things. Having a
> way to let the domain owner publish demands that are widely ignored
> indicates a seriously flawed semantic model. And that is, indeed, the
> current reality for DMARC.
>
You are fixated on what the receiver must or must not do. I never said
anything about that. That is a strawman. I'm pointing out that ARC is
trying to get two states out of reject where there only is one. It is
certainly not unreasonable for my bank to say "please reject anything
that is not by the letter of the law". I don't want somebody to figure
out how to game all of this ARC stuff to phish me from my bank. That is
far from unreasonable.

But you can say, no I am smarter than those banks and I REALLY REALLY
mean it, but I don't care.

Mike

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

_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
--------------475835F9D0C3D551D804E88B-- From nobody Sat Dec 5 17:48:07 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D66533A04BC for ; Sat, 5 Dec 2020 17:48:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.851 X-Spam-Level: X-Spam-Status: No, score=-1.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iecc.com header.b=un0oxGfo; dkim=pass (2048-bit key) header.d=taugh.com header.b=CqHkkL8U Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LnkuBisEjiP0 for ; Sat, 5 Dec 2020 17:48:04 -0800 (PST) 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 DABB33A048B for ; Sat, 5 Dec 2020 17:48:02 -0800 (PST) Received: (qmail 31068 invoked from network); 6 Dec 2020 01:48:00 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=7950.5fcc3850.k2012; bh=KDq/5+Xw520cDygdjBH7Yg7Y2uSW0KOnfdT7O7ZeDdU=; b=un0oxGfohThM3VeQabCsfGK8SauoS0Lifx/+NMGVGbNx+J6P5xeF5UNdXY0/c047cDH9GcZvEQtKreKBPLEFjChQW8cKY8J1TCROIuDnjDxmBs+sg3fPYJDiTpxIzn5IrSfekPlMUTu0Vf+2HiYefWGXLxpV/bx6bYiybdCY5TX3s0jB5uChUVkRQxBLCFvSOX9a9v/zkkuTY5zSZuyfPTKOeOrLcf7+Lb4oIbM/0mo7myonz9SQsI3L4iwN/kTmtc9QsvrTPaX1ZoYBnn8R8JkPXKhw4lvRu9W06oJUZQoMRERQZAgHZ41UxJv9hJnHc/CMP44cRdAIbwBr0uqk6Q== DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=7950.5fcc3850.k2012; bh=KDq/5+Xw520cDygdjBH7Yg7Y2uSW0KOnfdT7O7ZeDdU=; b=CqHkkL8UgHHeANl/iOs5yjEaZE8zG9AdKPTubIRvjQXXYA0UQnVGYXoGXBTuOid71kNcFEoseMsZpPJEhJS9NlwlEnJ3e6QMCTkNUgNd62KWQe4nas2N94yO55dQDM/hp7f4Y5i3K77eIMBRRxtPczM+i6/O9ZdDrHCISv06dftl/lJCIAlNiv5EiE6QMtlnE8M1AHMh55RlplhQWjXPk5IqIY02hB4VZUlZAK4US+2s9KExl8nQyFc8Of3tI0g9rJ00oqIB/ep9B5psTii0ZwQFiZtTBVfL33KuDjQQBN9QpWuLxB7AZKHlryaZ839C1O/ZrdP43e++ZrSNKMoE2w== Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2 ECDHE-RSA AES-256-GCM AEAD) via TCP6; 06 Dec 2020 01:48:00 -0000 Received: by ary.qy (Postfix, from userid 501) id 26A202910056; Sat, 5 Dec 2020 20:47:59 -0500 (EST) Date: 5 Dec 2020 20:47:59 -0500 Message-Id: <20201206014800.26A202910056@ary.qy> From: "John Levine" To: dmarc@ietf.org Cc: dcrocker@gmail.com In-Reply-To: Organization: Taughannock Networks X-Headerized: yes Cleverness: minimal Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] ARC vs reject X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 06 Dec 2020 01:48:06 -0000 In article you write: >The domain owner might want all sorts of unreasonable things. Having a >way to let the domain owner publish demands that are widely ignored >indicates a seriously flawed semantic model. And that is, indeed, the >current reality for DMARC. Thanks. Lest anyone think this is a new issue, see this message I sent to the DKIM list in 2006, fourteen years ago: https://mailarchive.ietf.org/arch/msg/ietf-dkim/CBsHbUVtM512vgiwljiA6dtVJ1Q/# I reprised it six years ago in 2014: https://mailarchive.ietf.org/arch/msg/ietf/ngPmSfa0b_B5Q72G1JwzGG2IYKY/ R's, John From nobody Sat Dec 5 17: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 5FE433A074E for ; Sat, 5 Dec 2020 17:51:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.651 X-Spam-Level: X-Spam-Status: No, score=-1.651 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, 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=mtcc-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NxbGeK6knHCi for ; Sat, 5 Dec 2020 17:51:57 -0800 (PST) Received: from mail-pj1-x102b.google.com (mail-pj1-x102b.google.com [IPv6:2607:f8b0:4864:20::102b]) (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 14EAE3A0656 for ; Sat, 5 Dec 2020 17:51:57 -0800 (PST) Received: by mail-pj1-x102b.google.com with SMTP id hk16so5378664pjb.4 for ; Sat, 05 Dec 2020 17:51:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mtcc-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=wLG2kuVKQAt8P3xoFh7X/tAYSgMZfxVt6imME82QyWo=; b=YqziekG9aDZG6dIAP631Ef9/0OjjeT00i0NClAouWynHFn3/K/fYQxYXbuyDh5wFw5 Q0niSHJz3v6lFz+47fnLLXNoSzLvkgiwTd6NYi3VNjYMABAb7Kx1sRAPObImYZ3aLDOO Z9ySrZ53m1thB9c54Oi1+afBIcmfY8kABLtc4o1B8tvh61gdImL6ZsDqgcsFKLrJXUjm 4VU307UBOUTsl4ICRP1+O6iTS++CimPObaUuTLq6zuhqgNa7Xao1ui3plKaIMpWKYiwU N/Vq8bOExzoee/vZDPGEg+JzYY7CX+5qr++bdvUHAJW0Blxj8fYhpW/WD5w6hfcZb70K FAYw== 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=wLG2kuVKQAt8P3xoFh7X/tAYSgMZfxVt6imME82QyWo=; b=phv95QxGn2Pu9BKJZzkb/z+dD2PwFEYLQnnpGPCl/oyCC20qfCHsumETrvYKYp1xro 6vfD7iAx1MBn54tvH7hSoweRqfRkGWU+OwoFMfJpHbkGf5R64dq1VTtug0R/zRmM1Suf h/FqaYWAOjAyUqfdn2LCH+Rp8t8i5oYY0kYAWL6kvb4vCbwqGkFlHp+EeBSF53VWiPhf MzMXzBnsbL3EN/xb0X5ffV9TuGIM/DX/Qi5U2XA0vkP4I/gUw2ssaj0qS821j/zNC71R DoeGP36tD9/r8BIrzLiHC7IsO/tfxfGxaqk5F/BrFk1CvN86AoUjOkkaGJR7RtOADp4L fRwg== X-Gm-Message-State: AOAM531a1XwsTSLWFRh7JUpUuUMrVZUG1QIHz1ZjjLgVp1pNE3mMnzfx a4Uj2kzKAs11fVVHLajk4AAxQfWnyHK2HA== X-Google-Smtp-Source: ABdhPJw/l6Bpao7M8p6PqVWk0+tDgttz1U+1C+2SVXVAEaOpgRuW/kd0tHORBUhA/gH6sAO4IpZyng== X-Received: by 2002:a17:902:8ec4:b029:d7:eb0d:84c0 with SMTP id x4-20020a1709028ec4b02900d7eb0d84c0mr9946660plo.23.1607219516196; Sat, 05 Dec 2020 17:51:56 -0800 (PST) Received: from mike-mac.lan (107-182-42-33.volcanocom.com. [107.182.42.33]) by smtp.gmail.com with ESMTPSA id q5sm6088059pjg.4.2020.12.05.17.51.55 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 05 Dec 2020 17:51:55 -0800 (PST) To: dmarc@ietf.org References: <20201206014800.26A202910056@ary.qy> From: Michael Thomas Message-ID: <635ac274-fdc7-219c-3e62-2c931a1bc265@mtcc.com> Date: Sat, 5 Dec 2020 17:51:54 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 MIME-Version: 1.0 In-Reply-To: <20201206014800.26A202910056@ary.qy> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] ARC vs reject X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 06 Dec 2020 01:51:58 -0000 On 12/5/20 5:47 PM, John Levine wrote: > In article you write: >> The domain owner might want all sorts of unreasonable things. Having a >> way to let the domain owner publish demands that are widely ignored >> indicates a seriously flawed semantic model. And that is, indeed, the >> current reality for DMARC. > Thanks. Lest anyone think this is a new issue, see this message I sent > to the DKIM list in 2006, fourteen years ago: > > https://mailarchive.ietf.org/arch/msg/ietf-dkim/CBsHbUVtM512vgiwljiA6dtVJ1Q/# > > I reprised it six years ago in 2014: > > https://mailarchive.ietf.org/arch/msg/ietf/ngPmSfa0b_B5Q72G1JwzGG2IYKY/ because a domain owner might want an unreasonable thing doesn't imply that a domain owner can't want a reasonable thing. this is a logical fallacy designed to dismiss any request as unreasonable. Mike From nobody Sat Dec 5 18:04: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 6CEF33A0A7E for ; Sat, 5 Dec 2020 18:04:48 -0800 (PST) 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 28CBaXi3LDz9 for ; Sat, 5 Dec 2020 18:04:47 -0800 (PST) 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 37A723A07D3 for ; Sat, 5 Dec 2020 18:04:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bluepopcorn.net; s=supersize; h=Content-Transfer-Encoding:Content-Type: MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From:Sender :Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=0X5eo8U00Ss2ixnmc2a8ZaxN6//Jk2auS/zvvURvTn8=; b=GjUAw1PLgBhffNlaBMzB3p5BDf tFRsFi9YKBFKJrNbQI2vxfYQgZDuPmeW6RHcmQUaW1EEFEPfzHqNAzicaKKQWnYEm/J2vk5xVRIHp 5TwI3WrbTDoa2i0YsxmKbcaZTK8cm3KRW7Z55eM2b5FRsmTHyBJHbJ8xveVjVONWweXQ=; Received: from [2601:647:4400:1261:7d1c:9b45:21bd:630e] (helo=[10.10.20.144]) by v2.bluepopcorn.net with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kljPp-0004no-Cy; Sat, 05 Dec 2020 18:04:45 -0800 From: "Jim Fenton" To: "John Levine" Cc: dmarc@ietf.org, mike@mtcc.com Date: Sat, 05 Dec 2020 18:04:44 -0800 X-Mailer: MailMate (1.13.2r5673) Message-ID: <28759E60-3A00-4D25-9490-34495B96EE10@bluepopcorn.net> In-Reply-To: <20201205210351.DB78E2904420@ary.qy> References: <20201205210351.DB78E2904420@ary.qy> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] ARC vs reject X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 06 Dec 2020 02:04:48 -0000 On 5 Dec 2020, at 13:03, John Levine wrote: > In article <4f2d2e0e-c773-95df-0958-12344e963b7a@mtcc.com> you write: >> >> As I understand ARC, it is means of transporting the original >> auth-res >> to the destination in case the origin signature is broken by an >> intermediary. From there the destination can decide one way or the >> other >> to override the DMARC policy of, say, reject. > > Right. > >> There are, however, use >> cases where that is exactly wrong and in no case does the originating >> domain want such an override to happen. Consider my bank sending me >> transactional email. If somehow somebody managed to get that mail >> through a mailing list and arc-resigned it, my bank does *not* want >> that >> mail to be delivered regardless of the reputation of the mailing list >> because something weird and wrong is happening on its face. > > If you get a message from a bank via a trustworthy mailing list with a > valid ARC chain that starts with a DMARC pass, that means someone at > the bank really did send the message to the list. I don't think it's > our job to try to guess whether the bank's users are following some > internal policy we can't see. I’d like to step back from the specific use case of “a bank”. If a domain publishes p=reject, they’re requesting particular handling of a message they originate. ARC modifies that, which is good for mailing lists and similar intermediaries, but depends on a list of trusted intermediaries that is not under the control of the originating domain. That increases the attack surface for DMARC considerably. The question I have is: Should DMARC have a policy (or policy modifier) that says, “Do not accept modifications to this message?” In other words, that the originator values the integrity of their messages over deliverability. -Jim From nobody Sat Dec 5 18:22: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 6B6133A0AC5 for ; Sat, 5 Dec 2020 18:22:24 -0800 (PST) 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 (2048-bit key) header.d=iecc.com header.b=MFTvTpSn; dkim=pass (2048-bit key) header.d=taugh.com header.b=hIAum9Hu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kzI_Pl5MCLO8 for ; Sat, 5 Dec 2020 18:22:22 -0800 (PST) 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 5B1A53A0AC1 for ; Sat, 5 Dec 2020 18:22:22 -0800 (PST) Received: (qmail 36621 invoked from network); 6 Dec 2020 02:22: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; s=8f0b.5fcc405a.k2012; i=johnl-iecc.com@submit.iecc.com; bh=3pM/psxG7K7AiYMPlFKi3yCZCJuMnUWi5dI3n4DntMo=; b=MFTvTpSnXl9sk/00wRyTJcmDl5LRXJ/TuIXlNmLEwVAbZEDXj6G1h9YJ8LN+dgeXbVs2ywqXjN5yRs77K3HPb5fw0M21sbp/3pv6dRcwH1MeC8wNY46CXfAOYIMl7MDHTviZ/BJlhxmjJV4apdj9yilEe+ZNM8obgB3Gyte9h2/jU1icV+w5xecQnUNRIoXlyRWoWQ7nPxhS4QpV4alBD/jdCB4lmnYcrGJejLm+3WWXweM8NLGf1GBi/e/XE1APNJOkfCNEdE6DIB/GJ/TTZwqMVkGu6S1EFU048Fqn55JnAHI8ofyNlI6viawJWiB5yt6xgqy8RL68gOi66jibXg== 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=8f0b.5fcc405a.k2012; olt=johnl-iecc.com@submit.iecc.com; bh=3pM/psxG7K7AiYMPlFKi3yCZCJuMnUWi5dI3n4DntMo=; b=hIAum9Hu3+eRjkXHlAbcAf8XqV+Ltv9LwJ7gKWsyhbZm99PXcIT3Kf5MLOtYOnLvVYyZBKUBta9a/9DRoaJsDHm8KRCUrSPbehKXRw4KsBiAhUctqVqbtcdp3kNuOGYlPwLWmrinhSaynMxUx2LMBhrrVjL6j3JAfJTlcjknw3Ts+4BKF+Sg4yOmSwmhzDFX9InAKQAIUz7g6j2Zkb0lP+fzRkvpE3YAx5CCWpwZ/jA/IU1qjHRse7/1keWAGSQTa+KU6fRP8EEmF57pA9iR6+6NorarESg44MTGQF+nPEfUmkA+YSfVb/Y99lHsu8Yn8m1/F87R+XeswwUzsoDCUg== 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 Dec 2020 02:22:18 -0000 Date: 5 Dec 2020 21:22:18 -0500 Message-ID: <9c23d850-4164-1320-1c25-40554c1f64b@taugh.com> From: "John R Levine" To: "Jim Fenton" Cc: dmarc@ietf.org In-Reply-To: <28759E60-3A00-4D25-9490-34495B96EE10@bluepopcorn.net> References: <20201205210351.DB78E2904420@ary.qy> <28759E60-3A00-4D25-9490-34495B96EE10@bluepopcorn.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="0-853666523-1607221338=:46099" Archived-At: Subject: Re: [dmarc-ietf] ARC vs reject X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 06 Dec 2020 02:22:24 -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-853666523-1607221338=:46099 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT > If a domain publishes p=reject, they’re requesting particular handling of a > message they originate. ARC modifies that, which is good for mailing lists > and similar intermediaries, but depends on a list of trusted intermediaries > that is not under the control of the originating domain. That increases the > attack surface for DMARC considerably. Not if the recipients use ARC reasonably, e.g., only on mail from hosts with a history of not sending botware, use it to see whether a message was originally aligned. Anyone who misuses ARC is going to have worse spam leakage than anyone can fix for them. > The question I have is: Should DMARC have a policy (or policy modifier) that > says, “Do not accept modifications to this message?” In other words, that the > originator values the integrity of their messages over deliverability. Of course not. That's just the tiny gorillas stamping their teensy feet. Why would anyone expect that the people publishing that flag actually understood what it meant? Many will just turn it on because someone said it's "more secure." A lot of this boils down to what if some entity sends signed valid DMARC aligned mail but somehow doesn't mean it, e.g., an internal policy says no mailing lists but their users participate in lists anyway. If they can't control their own mail system, it is not anyone else's job to do it for them. R's, John --0-853666523-1607221338=:46099-- From nobody Sat Dec 5 18:27: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 025F33A0AF7 for ; Sat, 5 Dec 2020 18:27:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.64 X-Spam-Level: X-Spam-Status: No, score=-1.64 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, T_SPF_TEMPERROR=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mtcc-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q-fF6PFd5Bna for ; Sat, 5 Dec 2020 18:27:04 -0800 (PST) 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 096113A0AF6 for ; Sat, 5 Dec 2020 18:27:03 -0800 (PST) Received: by mail-pg1-x52d.google.com with SMTP id n10so6047940pgv.8 for ; Sat, 05 Dec 2020 18:27:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mtcc-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=ZiDY7+ff1ErKmOdeBGf/ZOCnyr8/uaPf0tAAE7Dde2c=; b=pLqTnOmN+DW9wEKX5LVW8M3TF4WVNSiSyUP4SUfzBSoD9NCbnLpd2j2Qsd/ESHyz4L IRFW4nJzxWGnUWNIcy5CjunGRE0FNLVqCl+WMV3IrsTR77VaMi6Mdm5HAE6F0B0ZacMZ k4mkh0qJfMUCf1GyfU8DYOGAeanA9Nyc+JD47sx6B5gdJ8RIlLp00c6X2VzGpxxAau+L XKgm150ROUHfkjuNqE530PLd4k+iokX5rf3laGoCP4TTdvniKAUy3PYYgwmT8J6c8J3C XKPWF6s4h9Bsg405Qv9vBOP1W6Bc+qbdrhODuKySkjl1/Ay3owfDyFmwozv3fTWNOVcM 4t7w== 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=ZiDY7+ff1ErKmOdeBGf/ZOCnyr8/uaPf0tAAE7Dde2c=; b=A1IjkqJyQP95/UIkA5PbrqbRbqRPgSX6N+tEAg8EDWdWv1wIGVsSWHbVhPod33kzJ9 NPBGGQ5a8uyzpJ/dRamUtUs6akLSYW2YUfMO5RqTgM262HuDPHM+/+C9LQRuOFvBx8ri tVF039mfUe9ohp+L3WPG3yhFA3VOL0UmYUkkt/uwMXRvxduG4tvQFwCBWUrHCjGZtfpj ikaB2bPe0jzCRqPCIoe/7QshygI1TMfwAZeoFv0zt+hxLD+llZDAekzNi2n+JXjtxdHJ kqd04tsggnWISZAhmHnMxhqDFYIQ6eATwHzJ4hjljv1jpQZuHUQqSk+fifgdEh0HJgHo U4Hg== X-Gm-Message-State: AOAM533HWEE3YjSz7+WQtCrJMA+1AXv3jhqbzYNZqeAhrlt11eRmnGRI K3OJsV5Hc7XdUe18WWfimjKM7hzNTSw3Ww== X-Google-Smtp-Source: ABdhPJzdhJvDcrh19RrzJkjtnXWU1mtccot4gmsnqsOcvJhCmGiR9VwB4kbjs9AsbDhT9wVzeqE4dQ== X-Received: by 2002:a65:5944:: with SMTP id g4mr13499786pgu.446.1607221622856; Sat, 05 Dec 2020 18:27:02 -0800 (PST) Received: from mike-mac.lan (107-182-42-33.volcanocom.com. [107.182.42.33]) by smtp.gmail.com with ESMTPSA id f123sm9419232pfa.89.2020.12.05.18.27.01 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 05 Dec 2020 18:27:02 -0800 (PST) To: dmarc@ietf.org References: <20201205210351.DB78E2904420@ary.qy> <28759E60-3A00-4D25-9490-34495B96EE10@bluepopcorn.net> <9c23d850-4164-1320-1c25-40554c1f64b@taugh.com> From: Michael Thomas Message-ID: <23735838-82bb-d09d-a3f2-8a53af621467@mtcc.com> Date: Sat, 5 Dec 2020 18:27:00 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 MIME-Version: 1.0 In-Reply-To: <9c23d850-4164-1320-1c25-40554c1f64b@taugh.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] ARC vs reject X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 06 Dec 2020 02:27:08 -0000 On 12/5/20 6:22 PM, John R Levine wrote: >> The question I have is: Should DMARC have a policy (or policy >> modifier) that says, “Do not accept modifications to this message?” >> In other words, that the originator values the integrity of their >> messages over deliverability. > > Of course not.  That's just the tiny gorillas stamping their teensy > feet. Why would anyone expect that the people publishing that flag > actually understood what it meant?  Many will just turn it on because > someone said it's "more secure." Financial institutions are "tiny gorillas"? Who knew? The federal government is "tiny gorillas"? What is the metric here? Mike From nobody Sat Dec 5 18:31: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 98B883A0B16 for ; Sat, 5 Dec 2020 18:31:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.652 X-Spam-Level: X-Spam-Status: No, score=-1.652 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mtcc-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZuHRNbVmE_wF for ; Sat, 5 Dec 2020 18:31:21 -0800 (PST) Received: from mail-pf1-x433.google.com (mail-pf1-x433.google.com [IPv6:2607:f8b0: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 7D69C3A0B12 for ; Sat, 5 Dec 2020 18:31:21 -0800 (PST) Received: by mail-pf1-x433.google.com with SMTP id s21so6581778pfu.13 for ; Sat, 05 Dec 2020 18:31:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mtcc-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=ymVk8mmiK4nBoKdWaAviS46nXD3O/8NG5P2L/wgr+F4=; b=0HUTe5to7KRkCgQ/rmOHoSUVQcySH2VZs8duD2aKYoIZNSTse+fhq2AD0S7n7T2lr0 5iltM4+9mBAH98LFhbd/+sXIoMvxRNgo6lDOznk+sVyqZB/fg+sH58SJNU480qAlA6SZ vUdpJzss+h0Cm0NSRW1pw8f3qSBipYuwli3/XM/Oa1Zz7NbwGNI4SAMnc1pjLde+te+H kNNKywZP0B9qrD/EJCockx54FrHPn8cPr33IufHfQSSEPe858e+t3mtZV4TbV1B8W7m6 IUmLyrs5Bj54HeT4KVIIhoCYvR90r1A8kbC9snNY9+nc9PnzgbeqjBTrUGenwse1haW/ uNUw== 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=ymVk8mmiK4nBoKdWaAviS46nXD3O/8NG5P2L/wgr+F4=; b=V5yHgLezFHqUL/C6u/Ah+AF4BN/8cF10d1dqwQWMFxjbNdqbbGFywURW96Q53FhEbr 56zIrN7fbTTe6U+yP6R0N7x47jOL0e9vu0MQx/HDd4DENEDxZu4VhTiv+BzLqqQie33C EF3m/gkzKBCygactv93XwmN+H8T6mGpKEhs+cgWU8GoFzr8nafFJErRse871HHJoLkAB KHgAbUUeKQipSzoslc8tPeiJ6icz2DjLuIiWM5BlpYNhIj9Heyb3bhmCBxy9Uw/U7zRe WQhV2d8wPBXohR4IG6onNh+dKsemakGqboGF7ocfpcqMGTG+SGkI408sncHTNZ17L3MS gRkA== X-Gm-Message-State: AOAM532eN/PzFdgDRDkUrSN+uf5J5wHg8+YOJkD2OCVqxyyMjHYbtsu7 uzVusaj0SjeIYy53hFn0r2A2noAX0Hl1oQ== X-Google-Smtp-Source: ABdhPJw74VKuh9v7IJi07E8l85o8EBjIER2CJHMjAdMAh+KZogCUAEz9Pe/fJs//ny09D+DFZOpdrw== X-Received: by 2002:a63:4605:: with SMTP id t5mr13423902pga.244.1607221880427; Sat, 05 Dec 2020 18:31:20 -0800 (PST) Received: from mike-mac.lan (107-182-42-33.volcanocom.com. [107.182.42.33]) by smtp.gmail.com with ESMTPSA id y10sm6181817pjm.34.2020.12.05.18.31.19 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 05 Dec 2020 18:31:19 -0800 (PST) To: dmarc@ietf.org References: <20201205210351.DB78E2904420@ary.qy> <28759E60-3A00-4D25-9490-34495B96EE10@bluepopcorn.net> <9c23d850-4164-1320-1c25-40554c1f64b@taugh.com> From: Michael Thomas Message-ID: <3b0962fc-3988-b14e-e92e-be20d89c9040@mtcc.com> Date: Sat, 5 Dec 2020 18:31:18 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 MIME-Version: 1.0 In-Reply-To: <9c23d850-4164-1320-1c25-40554c1f64b@taugh.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] ARC vs reject X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 06 Dec 2020 02:31:23 -0000 On 12/5/20 6:22 PM, John R Levine wrote: > > > A lot of this boils down to what if some entity sends signed valid > DMARC aligned mail but somehow doesn't mean it, e.g., an internal > policy says no mailing lists but their users participate in lists > anyway.  If they can't control their own mail system, it is not anyone > else's job to do it for them. > PS: if IETF must assume that people cannot understand our standards and their intent, then we might as well shut down. if they cannot understand our intent, that is squarely on us, not them. This sort of cynicism is poisonous. Mike From nobody Sat Dec 5 19:33: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 C4B723A0C61 for ; Sat, 5 Dec 2020 19:33:19 -0800 (PST) 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 h7LD0fTOvjL1 for ; Sat, 5 Dec 2020 19:33:18 -0800 (PST) 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 7CB3D3A0AB4 for ; Sat, 5 Dec 2020 19:33:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bluepopcorn.net; s=supersize; h=Content-Type:MIME-Version:References: In-Reply-To:Message-ID:Date:Subject:Cc:To:From:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=0X68cydDcmm57O5CJi14Pvava98aTbGwirIvk1lhQLM=; b=m/QoZyIJk3j82mjN7VGC83pUA t3xIOBKzTRDas3NEA0koj/XKihovZQdrjas1wj/VX8P0vvIwINDuriIdAxVKrjqlPpA4UU2nOUlZn w/FYzMzYYcbRY4AKjni0q+YAVf1ZgTJO+4Yc88DPAfZaoSgah5tKsQR1mN3A/MetJzJmk=; Received: from [2601:647:4400:1261:7d1c:9b45:21bd:630e] (helo=[10.10.20.144]) by v2.bluepopcorn.net with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1klknS-000536-2S; Sat, 05 Dec 2020 19:33:14 -0800 From: "Jim Fenton" To: "Kurt Andersen" Cc: "Michael Thomas" , dmarc@ietf.org Date: Sat, 05 Dec 2020 19:33:13 -0800 X-Mailer: MailMate (1.13.2r5673) Message-ID: In-Reply-To: References: <134860ee-5fbf-2fb3-a5b3-4be68806ab22@mtcc.com> <7224575d-685f-5020-073e-c1880acecc88@mtcc.com> <7e459496-61f8-ddcd-713c-3b6be448090c@gmail.com> <2cecceac-1add-44ec-6e16-e157fee293fe@mtcc.com> <5a577765-4a0d-e1bf-5321-dfeff19d107e@gmail.com> <40d7e78e-7026-c65c-383c-df4e3c537de3@mtcc.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed Archived-At: Subject: Re: [dmarc-ietf] is DMARC informational? X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 06 Dec 2020 03:33:20 -0000 On 4 Dec 2020, at 15:00, Kurt Andersen (b) wrote: > The entire point of this working group (and the bis version that is in > progress) is to move DMARC into the fully-recognized "standards" > track. > Note that even the current email specs are not "standards" in IETF > parlance > (there's another WG addressing that). It's mostly organizational > semantic > slicing-and-dicing. The current email specs (specifically RFC 5321 and 5322) are Draft Standard, which is part of Standards Track. There is an enormous difference between Informational and Standards Track in terms of the amount of vetting and consensus required for approval. From RFC 2026: > An "Informational" specification is published for the general > information of the Internet community, and does not represent an > Internet community consensus or recommendation. -Jim From nobody Sat Dec 5 19:51:49 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9080C3A0C8F for ; Sat, 5 Dec 2020 19:51:48 -0800 (PST) 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=lJ75qO7G; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=rXrKQ4mp Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G0ZfuylOA5Ad for ; Sat, 5 Dec 2020 19:51:46 -0800 (PST) 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 65DBF3A0C8A for ; Sat, 5 Dec 2020 19:51:45 -0800 (PST) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1418; t=1607226700; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=nGnFfqpOQg0pWMB97ey7YYmfFg7d F+1h+3oSzg8sEqg=; b=lJ75qO7GPK3fiJwDFKI9qxoVvm7wN0sMGNMF90axsbDS mbSBCD0XX4o0TqSlsF+Ca3mnGgRU8r6LMfwwA575+Jlmdps3lVv9wZuFEUI/2wz0 QnuiQp21rFmWchd0EHDeq3+eYpPrjoYH31CPQ+xugHHZP2nnINqvoTWAX8VsBvc= Received: by mail.winserver.com (Wildcat! SMTP Router v8.0.454.10) for dmarc@ietf.org; Sat, 05 Dec 2020 22:51:40 -0500 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 666788696.1.876; Sat, 05 Dec 2020 22:51:40 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1418; t=1607226366; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=nGnFfqp OQg0pWMB97ey7YYmfFg7dF+1h+3oSzg8sEqg=; b=rXrKQ4mpekmTlHx1XfbxUEY AK9OWDurdn4C9ev3dt/u5T3Lf7JoDyh+dEyHXROB1g9vLTEumUgMmIXdMWeV0Pkx V1H34fuMcTTxcwmZahBhXVSr9mO3v0AMBdE08ag+pq+EudgkPnsJjUtq1NBBtVk1 sbWJViZO0HvRkfk7O5w8= Received: by beta.winserver.com (Wildcat! SMTP Router v8.0.454.10) for dmarc@ietf.org; Sat, 05 Dec 2020 22:46:06 -0500 Received: from [192.168.1.68] ([75.26.216.248]) by beta.winserver.com (Wildcat! SMTP v8.0.454.10) with ESMTP id 533670908.1.21768; Sat, 05 Dec 2020 22:46:05 -0500 Message-ID: <5FCC5550.3030501@isdg.net> Date: Sat, 05 Dec 2020 22:51:44 -0500 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: Michael Thomas , dmarc@ietf.org References: <20201205220233.18DCA2904B56@ary.qy> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] ARC vs reject X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 06 Dec 2020 03:51:49 -0000 On 12/5/2020 5:07 PM, Michael Thomas wrote: > > On 12/5/20 2:02 PM, John Levine wrote: >> OK, ARC doesn't do that. This does not mean that ARC is broken, only >> that you appear to have different policy priorities than other people. >> As you know, DMARC has never obliged recipients to follow senders' >> policies so this is nothing new. > > If ARC is advocating for a bypass of p=reject that introduces a new > state. If my policy is reject, I want you to reject the mail. If I > want you to reject the mail unless you think it has come from an > acceptable place with receipts, then you need a new policy tag like > reject-except-valid-arc. I have long suggested one way to resolve this is by using a new DMARC extended "arc=" switch. Allow the author domain define what is acceptable from an ARC standpoint, if interested. arc=N where N is the arc seal count, whatever amount is allow to "promote" a failed DKIM to a pass. The inherent default arc=0 would suggest arc should not be a consideration DKIM fails. In principle, I am for using DMARC extended switches to outline the different protocol behaviors. arc=1 DMARC Receiver MAY consider using arc for failure promotion atps=1 DMARC MAY consider using RFC6541 rewrite=0 Mailing List SHOULD NOT rewrite 5322.From Keep it simple folks. -- Hector Santos, https://secure.santronics.com https://twitter.com/hectorsantos From nobody Sat Dec 5 19:56: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 6157C3A0C9D for ; Sat, 5 Dec 2020 19:56:12 -0800 (PST) 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 DJAwkpShfFj8 for ; Sat, 5 Dec 2020 19:56:10 -0800 (PST) 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 B36893A0C9B for ; Sat, 5 Dec 2020 19:56:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bluepopcorn.net; s=supersize; h=Content-Transfer-Encoding:Content-Type: MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From:Sender :Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=XedvumPxX62cfOVkQBXa9FkCArfg/7boUtgS4nNX5f0=; b=t2HQWKMsRczk5ZdpiYglLwdUdD VHUJalhv8BWCzk704F5Q667BT8sLlFuDcKIWZV20EGNhpgHZHp273iSO+dW5LHDeqAUQqPdK4RAxG vOVNBiHZDvKbNaYOa3Z16dLwmAGHfFHufSBArFH7GAVz1aQSezyWxxpLVhHiHh4Hc8AI=; Received: from [2601:647:4400:1261:7d1c:9b45:21bd:630e] (helo=[10.10.20.144]) by v2.bluepopcorn.net with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kll9d-00057I-1w; Sat, 05 Dec 2020 19:56:09 -0800 From: "Jim Fenton" To: "John R Levine" Cc: dmarc@ietf.org Date: Sat, 05 Dec 2020 19:56:08 -0800 X-Mailer: MailMate (1.13.2r5673) Message-ID: In-Reply-To: <9c23d850-4164-1320-1c25-40554c1f64b@taugh.com> References: <20201205210351.DB78E2904420@ary.qy> <28759E60-3A00-4D25-9490-34495B96EE10@bluepopcorn.net> <9c23d850-4164-1320-1c25-40554c1f64b@taugh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8"; format=flowed; markup=markdown Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] ARC vs reject X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 06 Dec 2020 03:56:12 -0000 On 5 Dec 2020, at 18:22, John R Levine wrote: >> If a domain publishes p=reject, they’re requesting particular >> handling of a message they originate. ARC modifies that, which is >> good for mailing lists and similar intermediaries, but depends on a >> list of trusted intermediaries that is not under the control of the >> originating domain. That increases the attack surface for DMARC >> considerably. > > Not if the recipients use ARC reasonably, e.g., only on mail from > hosts with a history of not sending botware, use it to see whether a > message was originally aligned. Anyone who misuses ARC is going to > have worse spam leakage than anyone can fix for them. “Use ARC reasonably” then seems to depend on whether the recipient has a good reputation system for evaluating the trustworthiness of message modifiers. There isn’t a good track record in creating and deploying such reputation systems, as you well know. In this case specifically, there is the question of what happens when a domain user subscribes to a mailing list, or has their mail forwarded with modification, from a new intermediary. >> The question I have is: Should DMARC have a policy (or policy >> modifier) that says, “Do not accept modifications to this >> message?” In other words, that the originator values the integrity >> of their messages over deliverability. > > Of course not. That's just the tiny gorillas stamping their teensy > feet. Why would anyone expect that the people publishing that flag > actually understood what it meant? Many will just turn it on because > someone said it's "more secure." FWIW, I don’t think a lot of the people publishing p=reject understood the implications of that, either. This is not significantly more arcane. > A lot of this boils down to what if some entity sends signed valid > DMARC aligned mail but somehow doesn't mean it, e.g., an internal > policy says no mailing lists but their users participate in lists > anyway. If they can't control their own mail system, it is not anyone > else's job to do it for them. It isn’t a question of controlling their own mail system. One of the value propositions of DMARC is effectiveness against phishing. Suppose a phishing attacker composed a message purporting to be from someone the victim trusts (including a DKIM signature that doesn’t verify because the message has supposedly been modified), and then makes it look like it has been forwarded by a throw-away intermediary they control and adds valid ARC header fields signed by the supposed intermediary. If the recipient domain accepts modifications by zero-reputation intermediaries (because there are so many of them, after all), DMARC policy is ignored and the message is delivered normally. The premise of DMARC is that the originating domain has an interest in expressing how messages purporting to come from their domain should be handled, and this attack uses ARC to override that. I’d be interested in other opinions on this. Or whether this is a fundamental problem with ARC. -Jim From nobody Sat Dec 5 20:14: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 24FB93A0CD2 for ; Sat, 5 Dec 2020 20:14:23 -0800 (PST) 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_DNSWL_BLOCKED=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iecc.com header.b=Y30AboJ2; dkim=pass (2048-bit key) header.d=taugh.com header.b=I5gD9Mh0 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bq6J1cQvFHHf for ; Sat, 5 Dec 2020 20:14:21 -0800 (PST) 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 1FE813A0CD1 for ; Sat, 5 Dec 2020 20:14:20 -0800 (PST) Received: (qmail 57211 invoked from network); 6 Dec 2020 04:14:19 -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:content-id; s=df79.5fcc5a9b.k2012; i=johnl-iecc.com@submit.iecc.com; bh=+xlxFxSzRRT1pqXaq6Pp6jl9nb+C4qyBtwuquPYXBl4=; b=Y30AboJ2PGt7YmbZs6efroU/1h90u95Pb9v+biKJXz9L2re28Q2FSwvwDit8XM7xpNxJdqWV+h6Ts2vT2Czy0f2n0aTqQZC/8uoUYj5BfABkHKn8fI+XZ5P7O8dnbRZ7+C8Du5zgEhNzpxF+haiWij5v1FG8UKNinotb9pBrUqUDeakZU1Pvw7OB+9xkhPkeOSAX4YiAgRZb9XDxnYXIpnnI/FM8wkWxPOsjVrWBXGuo+3gBUoTG5so5wqg2N5qmaV4Wbi421ySduyKk/1UAFwTm1954P5jF5paIewSRhTgpJolWs/vwE8xuLWtCRfnqO24tLWl3+YmFrnkWYi04SQ== 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:content-id; s=df79.5fcc5a9b.k2012; olt=johnl-iecc.com@submit.iecc.com; bh=+xlxFxSzRRT1pqXaq6Pp6jl9nb+C4qyBtwuquPYXBl4=; b=I5gD9Mh0sl6gk3uqmGwfT0uz5Q3itEz1ym0VWFY48+1Q3nQlt6LwBLu199HK9rrxXddnmVWqF+yIedNOwJmQSIkYnJ6aGizqi4fEQ74+FuYligYWOIcIhASBP1nChJeSXJfI2YpVvqAL0QvUyvf1BkD7faiXTOxmEQKljBfDSgVpwVRUb6eXffvUBNJlh+nPPa5R632OrmT+vxvQ3lL3w5/2ZKqrbiU5vOVEXc0Thfxw71AdiMcBueQVnZCYqmPC8TlBoskXn85ywFUaNe8Z5S368eRaMmHFQ3/3q7enZVJPWtmrRwoxOUJBCnEOAjIcmcAUcpc84SJ3g7yizckudQ== 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 Dec 2020 04:14:18 -0000 Date: 5 Dec 2020 23:14:18 -0500 Message-ID: From: "John R Levine" To: "Jim Fenton" Cc: dmarc@ietf.org In-Reply-To: References: <20201205210351.DB78E2904420@ary.qy> <28759E60-3A00-4D25-9490-34495B96EE10@bluepopcorn.net> <9c23d850-4164-1320-1c25-40554c1f64b@taugh.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="0-220286709-1607227744=:47280" Content-ID: <4048e8b-782a-b050-7d7-94d2a667746c@iecc.com> Archived-At: Subject: Re: [dmarc-ietf] ARC vs reject X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 06 Dec 2020 04:14: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-220286709-1607227744=:47280 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT Content-ID: <63ba6958-7831-7135-eacb-2a6aaa7555ea@iecc.com> On Sat, 5 Dec 2020, Jim Fenton wrote: >> Of course not. That's just the tiny gorillas stamping their teensy feet. >> Why would anyone expect that the people publishing that flag actually >> understood what it meant? Many will just turn it on because someone said >> it's "more secure." > > FWIW, I don’t think a lot of the people publishing p=reject understood the > implications of that, either. This is not significantly more arcane. Then I think we agree. There's no difference from p=reject and p=reject-I-really-mean it. > ... If the recipient domain accepts modifications by zero-reputation > intermediaries (because there are so many of them, after all) I wouldn't call that a reasonable implementation of ARC. The set of hosts that are likely to send you mail with interesting ARC chains is relatively small, and I don't think it changes very fast. Most of the hosts that send you non-spam mail aren't going to send you mail that needs ARC. If you're setting up a new mailing list host or forwarder, getting yourself into whatever whitelists people use will be somewhat painful but there's nothing new about that. > I’d be interested in other opinions on this. Or whether this is a fundamental > problem with ARC. I'd certainly be interested in hearing how people plan to compile and maintain their lists of ARC-worthy hosts. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly --0-220286709-1607227744=:47280-- From nobody Sat Dec 5 20:18: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 DE7363A0CE1 for ; Sat, 5 Dec 2020 20:18:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.652 X-Spam-Level: X-Spam-Status: No, score=-1.652 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mtcc-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iq3Wd0_9AlJ6 for ; Sat, 5 Dec 2020 20:18:41 -0800 (PST) Received: from mail-pl1-x630.google.com (mail-pl1-x630.google.com [IPv6:2607:f8b0:4864:20::630]) (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 4C2A63A0CE6 for ; Sat, 5 Dec 2020 20:18:41 -0800 (PST) Received: by mail-pl1-x630.google.com with SMTP id j1so5368689pld.3 for ; Sat, 05 Dec 2020 20:18:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mtcc-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=r79mSKMhro0ny8FHnJanijzU4wDYiatAVm7TOkRD0GE=; b=Ex4Uf4vpudIssEIBxyfmdEUm0g8AJbkHaOvmgIbETppIme8/t5XNIIKoDfTNCAJOfK VQD9dOtusdy0nDgqjkY4BmtaE44q2pBbf/aNkbLHJ7WvatJGOgX3OxkGbG8VppS2dTaW eqRJ5eIRVRS3agFMwZefzuFui9ctry/4or66ue5vUwBzRsSapNXamncYxpjGQF8F2IBz pzfkGuQmb5EJ69tOkWeFprGfmrC4Ns28zFmpz7FbFN+bHjqBOEMvwo4mJAgCJwRFpmVY G9BdkIndOclgRuXoGEB9hGxFttZRS/RfmMW56b3QLZOA8kzggliQ3gCEGkExICySFCTP ZD/A== 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=r79mSKMhro0ny8FHnJanijzU4wDYiatAVm7TOkRD0GE=; b=myscDuCwQ8CayxpVK2Lr6iSUMHu8/NAJ0lsv5IleClK6I9q0+hPBFh53BsCshCu/6U AYc/nPYSyj5ZyaIwaXlReV16qeXyi5UzchhaZ99Es6/ZlmHlL2FFZ28WMPotbWkXN85g I7KD0MxYRP3dQGiI/bT63z+8nNGdsW1pui4hdJN1f0qXylQ+cpPG4i5B0tKfIgH8kI1K drQXDOwJCIVipdvol0lTl8UKRWtuU/Aoy5GRSl20On1O6DT/A7vbUk/ZubZ/Dizbm9nM Y105RHEVey0MW2Uic3xOfFA7OuuYS/v8xFUEVO0ZkNjvcgAcNJulhJEzQLUE0+5Xkp7u YryQ== X-Gm-Message-State: AOAM531giz1gsfQursNgOHsYsuEwHrO2/btyDog6e663L+Ts956Pqg71 7kkd3P+QKEjxeZnqwUfZQFk/AHszBdAE+Q== X-Google-Smtp-Source: ABdhPJwDtZr/O9ZVeE2T8Zu6TXM0F9J2svaGrT4jhZYEUGh8Ns3g1RT8burL7NHRQJIcl+0q7AAOhQ== X-Received: by 2002:a17:902:b688:b029:d9:d374:68d with SMTP id c8-20020a170902b688b02900d9d374068dmr10573920pls.9.1607228319707; Sat, 05 Dec 2020 20:18:39 -0800 (PST) Received: from mike-mac.lan (107-182-42-33.volcanocom.com. [107.182.42.33]) by smtp.gmail.com with ESMTPSA id 14sm9995708pfz.54.2020.12.05.20.18.38 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 05 Dec 2020 20:18:38 -0800 (PST) To: dmarc@ietf.org References: <20201205210351.DB78E2904420@ary.qy> <28759E60-3A00-4D25-9490-34495B96EE10@bluepopcorn.net> <9c23d850-4164-1320-1c25-40554c1f64b@taugh.com> From: Michael Thomas Message-ID: <6b50c95c-b994-16ec-e9ae-9f08d7cdcb25@mtcc.com> Date: Sat, 5 Dec 2020 20:18:37 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.5.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] ARC vs reject X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 06 Dec 2020 04:18:43 -0000 On 12/5/20 8:14 PM, John R Levine wrote: > On Sat, 5 Dec 2020, Jim Fenton wrote: >>> Of course not.  That's just the tiny gorillas stamping their teensy >>> feet. Why would anyone expect that the people publishing that flag >>> actually understood what it meant?  Many will just turn it on >>> because someone said it's "more secure." >> >> FWIW, I don’t think a lot of the people publishing p=reject >> understood the implications of that, either. This is not >> significantly more arcane. > > Then I think we agree.  There's no difference from p=reject and > p=reject-I-really-mean it. If the operating assumption is that people implementing DMARC is that they are all illiterate, then our project is done. Mike From nobody Sun Dec 6 03:00:12 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EF163A0C37 for ; Sun, 6 Dec 2020 03:00:10 -0800 (PST) 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 koOO3f9KGs7L for ; Sun, 6 Dec 2020 03:00:08 -0800 (PST) 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 013183A0C35 for ; Sun, 6 Dec 2020 03:00:07 -0800 (PST) Received: (qmail 71307 invoked by uid 100); 6 Dec 2020 11:00:06 -0000 Date: 6 Dec 2020 10:59:42 -0000 Message-ID: <20201206105942.71290.qmail@submit.iecc.com> From: "John Levine" To: dmarc@ietf.org Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Archived-At: Subject: [dmarc-ietf] Messages from the dmarc list for the week ending Sun Dec 6 06:00:05 2020 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Dec 2020 11:00:10 -0000 Count | Bytes | Who ------------+----------------+------- 35 (24.0%) | 311900 (26.3%) | Michael Thomas 28 (19.2%) | 154564 (13.1%) | John Levine 20 (13.7%) | 134094 (11.3%) | Dave Crocker 15 (10.3%) | 84752 ( 7.2%) | Alessandro Vesely 8 ( 5.5%) | 134799 (11.4%) | Brandon Long 6 ( 4.1%) | 32478 ( 2.7%) | Jim Fenton 4 ( 2.7%) | 56114 ( 4.7%) | Douglas Foster 4 ( 2.7%) | 37717 ( 3.2%) | Dotzero 3 ( 2.1%) | 36154 ( 3.1%) | Todd Herr 3 ( 2.1%) | 34071 ( 2.9%) | Brotman, Alex 3 ( 2.1%) | 17915 ( 1.5%) | Steven M Jones 2 ( 1.4%) | 31600 ( 2.7%) | Laura Atkins 2 ( 1.4%) | 28707 ( 2.4%) | Seth Blank 2 ( 1.4%) | 17542 ( 1.5%) | Murray S. Kucherawy 2 ( 1.4%) | 14183 ( 1.2%) | Дилян Палаузов 2 ( 1.4%) | 7919 ( 0.7%) | Benny Lyne Amorsen 1 ( 0.7%) | 12599 ( 1.1%) | Ken O'Driscoll 1 ( 0.7%) | 9990 ( 0.8%) | Tim Wicinski 1 ( 0.7%) | 6694 ( 0.6%) | Joseph Brennan 1 ( 0.7%) | 5928 ( 0.5%) | Kurt Andersen (b) 1 ( 0.7%) | 5859 ( 0.5%) | Hector Santos 1 ( 0.7%) | 4429 ( 0.4%) | Benny Pedersen 1 ( 0.7%) | 3990 ( 0.3%) | From nobody Sun Dec 6 03:32: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 8546B3A0C83 for ; Sun, 6 Dec 2020 03:32:04 -0800 (PST) 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 5orl7fq-f72x for ; Sun, 6 Dec 2020 03:32:02 -0800 (PST) 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 58B3D3A0C81 for ; Sun, 6 Dec 2020 03:32:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1607254318; bh=INIca+U4oeDrmKQEbdtVcE82NjHh56YEXum3EP3BOrI=; l=1818; h=To:References:From:Date:In-Reply-To; b=C7IRs7wKo3gXZb3fy3rQYpT5yMdkJGU/65m+r3iAoj71PsDV9L4sK83ZqDiM2aTj5 lGqID3+KFtvHG3eAS/5o/jnKBUDU2RyN+1CNvSj9e/s8qCiFRCSILRcfRtxfh60ZMH SB0cbT0W2uSKe4yS6XLmqUwCPXmQgiP4PQdHKyxaaY6ogCm6ixAEeW6YMKFHQ Authentication-Results: tana.it; auth=pass (details omitted) Original-From: Alessandro Vesely 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.000000005FCCC12E.00003BAB; Sun, 06 Dec 2020 12:31:58 +0100 To: John Levine , dmarc@ietf.org References: <20201205210639.54261290454A@ary.qy> From: Alessandro Vesely Message-ID: <570ba614-a138-8a83-eae1-e6077b82937f@tana.it> Date: Sun, 6 Dec 2020 12:31:57 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: <20201205210639.54261290454A@ary.qy> Content-Type: text/plain; charset=us-ascii Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Ticket #42 - Expand DMARC reporting URI functionality X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 06 Dec 2020 11:32:05 -0000 On Sat 05/Dec/2020 22:06:38 +0100 John Levine wrote: > In article you write: > >> The VALCHAR element in Section 3.2 of RFC 6376 accepts "/", which is seldom used in email addresses and >> ubiquitous in https URIs. We could convene that when a mailto is to be considered as an alternative ... > > If we want to do something like that, I would overload the existing > !size hack. For example, add an "f" for finished flag and say that the > URIs are conceptually processed from left to right and if you send > your report to one with a !f (or !10mf or the like) flag, you can stop. Legacy producers unable to interpret "f" may discard the whole URI. > Still not convinced this is useful but it is slightly more backward > compatible. For backward compatibility, one could add a comma before the OR-slash: v=DMARC1; p=none; rua=mailto:local@example.com, mailto:report@service.example, /https://service.example/report/; A legacy producer will discard "/https" as an unknown scheme. It would have discarded "https" as well. Am upgraded producer can interpret a leading slash as introducing an alternative to the preceding destination. Possibly, there can be a series of them, to allow for secondary servers in case the previous URI fails. The first scheme without a leading slash introduces a new series of alternatives. For compatibility, mailto has to be the first URI of each series. Logically, however, it must be considered to be the last alternative. In fact, sending mail can only fail if the local submission server is unavailable. So it doesn't make sense to have multiple mailto's in the same series. This, the fact that supporting mailto is mandated, and backward compatibility justify the logic exception. Best Ale -- From nobody Sun Dec 6 04:06: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 930093A0CD4 for ; Sun, 6 Dec 2020 04:06:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.12 X-Spam-Level: X-Spam-Status: No, score=-2.12 tagged_above=-999 required=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_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 nSa8OgDvcG-v for ; Sun, 6 Dec 2020 04:06:16 -0800 (PST) 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 7C7843A0CD5 for ; Sun, 6 Dec 2020 04:06:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1607256373; bh=f4qTKLaRukB0C3cDcaQlqxTZEtuuWsGZNcuIKKwJ2rA=; l=1554; h=To:References:From:Date:In-Reply-To; b=BxYpxCxrj2SWglq4TNY7xYqgJ7M9udOcbggBzZcJ4wQ+z+g7Xd/YkWZRLbnXEzmwk S4U0QLuVI8UKCZP1PovPrXnet8IVBFFBgdZpviB8+Scb3+b/ZHgorZTBHct0TGmWcd 1lRD0jlTXJSmPooS3WuaoakgAEewmTGRdKq8Z19CyDUVld0q4f1LOvX7y2HKA Authentication-Results: tana.it; auth=pass (details omitted) Original-From: Alessandro Vesely 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.000000005FCCC935.00003EAB; Sun, 06 Dec 2020 13:06:13 +0100 To: dmarc@ietf.org References: From: Alessandro Vesely Message-ID: Date: Sun, 6 Dec 2020 13:06:12 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Discussion: Removal of validation for external destinations (Ticket #76) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 06 Dec 2020 12:06:19 -0000 On Sat 05/Dec/2020 14:51:52 +0100 Brotman, Alex wrote: > > There's currently a ticket that suggests that the requirement for external validation be removed. Today, if example.com has an RUA that points at example.net, the latter must create a record as such: > > example.com._report._dmarc.example.net TXT "v=DMARC1" Actually, the record can also be: example.com._report._dmarc.example.net TXT "v=DMARC1; rua=updated-address@example.net" or even, considering a parallel thread: example.com._report._dmarc.example.net TXT "v=DMARC1; rua=report@example.net, /https://www.example.net/report/" That way, external services have the ability to control or suspend their service. I think this is an essential requirement. Let's keep it. > The original thought was that a bad actor could overwhelm a target with unrequested reports. It seems in reality, most report generators only send once per day. Once-per-day has to be amended. See ticket #71. > Additionally, there appear to be some generators who ignore the absence of these records. Aggregate reports are often tagged as spam anyway, but when sent in violation of the spec such tagging is certainly deserved. > https://tools.ietf.org/html/rfc7489#section-7.1 Why don't you refer to either of the drafts we're editing: https://tools.ietf.org/html/draft-ietf-dmarc-aggregate-reporting-00#section-2.1 https://tools.ietf.org/html/draft-ietf-dmarc-failure-reporting-00#section-3.2 BTW, this duplication is worth yet another ticket. Best Ale -- From nobody Sun Dec 6 04:42: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 943E23A0D21 for ; Sun, 6 Dec 2020 04:42:18 -0800 (PST) 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 T-CtL-qLKou9 for ; Sun, 6 Dec 2020 04:42:17 -0800 (PST) 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 D8C353A0D04 for ; Sun, 6 Dec 2020 04:42:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1607258532; bh=aN73WwW3a/5p/ikoNPlD5E3ExVGxIw12iizBx7mFn6o=; l=1230; h=To:References:From:Date:In-Reply-To; b=BlFuYFJZ1IL5LcvhJQwAHdzgSCKIZ9sg4KqxPiIxKYIh1kRKEE7h/SkiCsXIgrIlo NLrfy4UabtOa1aQgk3Zp37eNp75KXuTtdjThC+n3OsiWL7hEa2XPdKV5ewE6euOhK8 yaPTmQaZmYq0kOrsZCiTwqqxfGeFTegHM2AuLn4v//a5cKVDzKXfsyof+62o+ Authentication-Results: tana.it; auth=pass (details omitted) Original-From: Alessandro Vesely 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 00000000005DC03D.000000005FCCD1A4.0000423D; Sun, 06 Dec 2020 13:42:12 +0100 To: dmarc@ietf.org References: <134860ee-5fbf-2fb3-a5b3-4be68806ab22@mtcc.com> <7224575d-685f-5020-073e-c1880acecc88@mtcc.com> <7e459496-61f8-ddcd-713c-3b6be448090c@gmail.com> <2cecceac-1add-44ec-6e16-e157fee293fe@mtcc.com> <5a577765-4a0d-e1bf-5321-dfeff19d107e@gmail.com> <40d7e78e-7026-c65c-383c-df4e3c537de3@mtcc.com> From: Alessandro Vesely Message-ID: <18e93db9-bde7-bf49-670c-1e680f2ce3a6@tana.it> Date: Sun, 6 Dec 2020 13:42:12 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] is DMARC informational? X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 06 Dec 2020 12:42:19 -0000 On Sun 06/Dec/2020 04:33:13 +0100 Jim Fenton wrote: > On 4 Dec 2020, at 15:00, Kurt Andersen (b) wrote: > >> The entire point of this working group (and the bis version that is in >> progress) is to move DMARC into the fully-recognized "standards" track. >> Note that even the current email specs are not "standards" in IETF parlance >> (there's another WG addressing that). It's mostly organizational semantic >> slicing-and-dicing. > > The current email specs (specifically RFC 5321 and 5322) are Draft Standard, > which is part of Standards Track. There is an enormous difference between > Informational and Standards Track in terms of the amount of vetting and > consensus required for approval. From RFC 2026: > > An "Informational" specification is published for the general information > of the Internet community, and does not represent an Internet community > consensus or recommendation. However, discussion and consensus which led to RFC 7489 were not much different from the process that is taking place now. This mailing list started in April 2013. Previous discussion took place elsewhere. There is still a 2011 draft at: https://dmarc.org/draft-dmarc-base-00-01.txt Best Ale -- From nobody Sun Dec 6 04:47: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 5EAD93A0D35 for ; Sun, 6 Dec 2020 04:47:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.651 X-Spam-Level: X-Spam-Status: No, score=-1.651 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, 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=mtcc-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G-KKFBsAUwBs for ; Sun, 6 Dec 2020 04:47:02 -0800 (PST) Received: from mail-pg1-x529.google.com (mail-pg1-x529.google.com [IPv6:2607:f8b0:4864:20::529]) (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 0E2EF3A0D32 for ; Sun, 6 Dec 2020 04:47:01 -0800 (PST) Received: by mail-pg1-x529.google.com with SMTP id o5so6575319pgm.10 for ; Sun, 06 Dec 2020 04:47:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mtcc-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=d5umL8cS5xXT14+ViZxRs2gHlmiirYGzTYyag6AwskQ=; b=VlE12cqNvGMTnvffg17/6/lVkOhTkiYmeseD6Fs+jQbwZ4UeA4BkcPp8BHu0Sep7E5 TjwrsnhxkkiAGpytL4UvelFrrp3GUBcLkh2al+0SfxOl/BbT+SX5GnKJ887GLAsbd5hd PWMkg6YY6IrQUalmP46GXscPH5XDJIL5tJW43n/4trFZkeSoxt2s48IouBtkmblE4eRC MjPKg8sHOvtzvfaAUxuWbab16xg4A6vLSf7o5CFE1wOdu9YSIhvbejAWnX1Lox8ORz6I AeiqaQLOUhVzwrDGgKOG/oOWUsdWjLvKaWrzq1Zs8unwx7ow51qOarDxwfX3707QE8dL 7TrA== 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=d5umL8cS5xXT14+ViZxRs2gHlmiirYGzTYyag6AwskQ=; b=Jzv0ZBjujoavD14yTdXfyAYM+bsmdevk2N5C3s+uhwVWyRISX3RmKA/eaeFtn3CmGC S5CR7viAAp/L4291+NJEtG7fXeoyV2lh3jqrgwp/K92FqSpKoI8jetKFizO8NeDEFxL6 KlMJhKIuUvbF9rQZoIFmqCYUxk76iJWqlL5Bb8Tkq0Z5Xd8ruF8Q6O0TE7W04ys16BG+ e/45GbZ+m/Ut0ErEq0hSrZAosrR2e+ApaJREIQb6tdrJwOdpCKuics7Nu8O+TuMX0YeC gvELuo+88BqJnCbP2gc8weEHbtcOy7aeidiTdXvO+vdD23ftUV2UGnrmF1/7sW+1zKf8 Qbjg== X-Gm-Message-State: AOAM531Jrpk4o9BfcMn0b1uWrE1x2h+/96CAt4MSbBzUfoRteG/1WwtE y9uy0SMqGq66g42+ml4ImwMmyju9G1UZZA== X-Google-Smtp-Source: ABdhPJzuQwk1Dwwuho4ewFkKbZKq6oeGUQmlT015V0d0nDlUj/EZ14z6MkbmR3a8FIPF8Vz5OJXgYQ== X-Received: by 2002:aa7:8813:0:b029:19d:cd3b:6f89 with SMTP id c19-20020aa788130000b029019dcd3b6f89mr7958005pfo.42.1607258820901; Sun, 06 Dec 2020 04:47:00 -0800 (PST) Received: from mike-mac.lan (107-182-42-33.volcanocom.com. [107.182.42.33]) by smtp.gmail.com with ESMTPSA id s5sm7931733pju.9.2020.12.06.04.46.59 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 06 Dec 2020 04:47:00 -0800 (PST) To: dmarc@ietf.org References: <134860ee-5fbf-2fb3-a5b3-4be68806ab22@mtcc.com> <7224575d-685f-5020-073e-c1880acecc88@mtcc.com> <7e459496-61f8-ddcd-713c-3b6be448090c@gmail.com> <2cecceac-1add-44ec-6e16-e157fee293fe@mtcc.com> <5a577765-4a0d-e1bf-5321-dfeff19d107e@gmail.com> <40d7e78e-7026-c65c-383c-df4e3c537de3@mtcc.com> <18e93db9-bde7-bf49-670c-1e680f2ce3a6@tana.it> From: Michael Thomas Message-ID: <65bbc2a6-701a-1729-7892-ef68c1b6b237@mtcc.com> Date: Sun, 6 Dec 2020 04:46:58 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 MIME-Version: 1.0 In-Reply-To: <18e93db9-bde7-bf49-670c-1e680f2ce3a6@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] is DMARC informational? X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 06 Dec 2020 12:47:03 -0000 On 12/6/20 4:42 AM, Alessandro Vesely wrote: > On Sun 06/Dec/2020 04:33:13 +0100 Jim Fenton wrote: >> On 4 Dec 2020, at 15:00, Kurt Andersen (b) wrote: >> >>> The entire point of this working group (and the bis version that is >>> in progress) is to move DMARC into the fully-recognized "standards" >>> track. Note that even the current email specs are not "standards" in >>> IETF parlance (there's another WG addressing that). It's mostly >>> organizational semantic slicing-and-dicing. >> >> The current email specs (specifically RFC 5321 and 5322) are Draft >> Standard, which is part of Standards Track. There is an enormous >> difference between Informational and Standards Track in terms of the >> amount of vetting and consensus required for approval. From RFC 2026: >> >>     An "Informational" specification is published for the general >> information >>     of the Internet community, and does not represent an Internet >> community >>     consensus or recommendation. > > > However, discussion and consensus which led to RFC 7489 were not much > different from the process that is taking place now.  This mailing > list started in April 2013. > > Previous discussion took place elsewhere.  There is still a 2011 draft > at: > https://dmarc.org/draft-dmarc-base-00-01.txt > And SSP was started in 2004. What's your point? Mike, i swear it's deja vu all over again From nobody Sun Dec 6 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 A65953A0D4C for ; Sun, 6 Dec 2020 05:08:56 -0800 (PST) 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 zF1t3zgn3iSg for ; Sun, 6 Dec 2020 05:08:55 -0800 (PST) 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 B64DE3A0D64 for ; Sun, 6 Dec 2020 05:08:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1607260132; bh=HvTeD3aM4xAMnZs8IyKCfMwzKVYB8efcHFb3G5ZH9jc=; l=1700; h=To:References:From:Date:In-Reply-To; b=Bmu1Rskb6uPDPwchCL9A/rUnWAiZYfROE1PEjX+tP1xV3Ub9SeqU2GPXYkVit0sTP 9Dre6AImC6jA73Q6oNyw5itzDBmQPNGlP88DiwRAwVl/lRh1DuCm5nN6YeGL67ifVB slBF/sHtTtMWvOvqQvGFtGc0TxYoxIDRtMGVeTX3OYZxxeUYUM+IC/xRDyMfh Authentication-Results: tana.it; auth=pass (details omitted) Original-From: Alessandro Vesely 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 00000000005DC0C3.000000005FCCD7E4.000044EB; Sun, 06 Dec 2020 14:08:52 +0100 To: dmarc@ietf.org References: <134860ee-5fbf-2fb3-a5b3-4be68806ab22@mtcc.com> <7224575d-685f-5020-073e-c1880acecc88@mtcc.com> <7e459496-61f8-ddcd-713c-3b6be448090c@gmail.com> <2cecceac-1add-44ec-6e16-e157fee293fe@mtcc.com> <5a577765-4a0d-e1bf-5321-dfeff19d107e@gmail.com> <40d7e78e-7026-c65c-383c-df4e3c537de3@mtcc.com> <18e93db9-bde7-bf49-670c-1e680f2ce3a6@tana.it> <65bbc2a6-701a-1729-7892-ef68c1b6b237@mtcc.com> From: Alessandro Vesely Message-ID: <5bce5710-6553-36ee-c46e-cbde702141e5@tana.it> Date: Sun, 6 Dec 2020 14:08:52 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: <65bbc2a6-701a-1729-7892-ef68c1b6b237@mtcc.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] is DMARC informational? X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 06 Dec 2020 13:08:57 -0000 On Sun 06/Dec/2020 13:46:58 +0100 Michael Thomas wrote: > On 12/6/20 4:42 AM, Alessandro Vesely wrote: >> On Sun 06/Dec/2020 04:33:13 +0100 Jim Fenton wrote: >>> On 4 Dec 2020, at 15:00, Kurt Andersen (b) wrote: >>> >>>> The entire point of this working group (and the bis version that is in >>>> progress) is to move DMARC into the fully-recognized "standards" track. >>>> Note that even the current email specs are not "standards" in IETF parlance >>>> (there's another WG addressing that). It's mostly organizational semantic >>>> slicing-and-dicing. >>> >>> The current email specs (specifically RFC 5321 and 5322) are Draft Standard, >>> which is part of Standards Track. There is an enormous difference between >>> Informational and Standards Track in terms of the amount of vetting and >>> consensus required for approval. From RFC 2026: >>> >>>     An "Informational" specification is published for the general information >>>     of the Internet community, and does not represent an Internet community >>>     consensus or recommendation. >> >> >> However, discussion and consensus which led to RFC 7489 were not much >> different from the process that is taking place now.  This mailing list >> started in April 2013. >> >> Previous discussion took place elsewhere.  There is still a 2011 draft at: >> https://dmarc.org/draft-dmarc-base-00-01.txt >> > And SSP was started in 2004. What's your point? On chartering the WG in 2013, the decision was made to publish DMARC as independent submission, even though it was going to be discussed and reach consensus of a IETF WG. AIUI, that was the original question of this thread. Best Ale -- From nobody Sun Dec 6 05:35: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 27AE43A0DAC for ; Sun, 6 Dec 2020 05:35:53 -0800 (PST) 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 DMCMS5rIoGr4 for ; Sun, 6 Dec 2020 05:35:51 -0800 (PST) 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 6B9323A0DAE for ; Sun, 6 Dec 2020 05:35:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1607261749; bh=HSUcqvB/LPMz0Hd93qUTW9rzVeYLZBMJ5YAxlNKi51Q=; l=1621; h=To:References:From:Date:In-Reply-To; b=C/CqFyX2IZ5ZmGB9XiDfHXlcQs0X43qJXzxQ7tERk93ZE08vDimXJMO+0K3Q7Qizy GVORdUao9cbnLUoTDxbr84ha4QbkaoU85pw+Y/3OHfW4+OASMMYeorMTj+R2rHgM/m 9xjpYYXEKdXLD2CXz5ttZ4fB/qNJuArGu1IAaDGQsSkuv/CkNtZlpaz3QRWOv Authentication-Results: tana.it; auth=pass (details omitted) Original-From: Alessandro Vesely 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 00000000005DC03D.000000005FCCDE35.00004759; Sun, 06 Dec 2020 14:35:49 +0100 To: dmarc@ietf.org References: <20201205231059.2BA23290EDCD@ary.qy> <7ae42764-176d-11a8-e084-b10b6f676944@mtcc.com> <8142f18c-ac79-1f94-97d1-2704f0b4ceb6@mtcc.com> From: Alessandro Vesely Message-ID: Date: Sun, 6 Dec 2020 14:35:49 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] ARC vs reject X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 06 Dec 2020 13:35:53 -0000 On Sun 06/Dec/2020 02:20:47 +0100 Douglas Foster wrote: > 4) On the future of ARC:   The idea is harmless, but I do not see it > achieving the list-industry goal of eliminating From rewrite.  It actually > reminds me of DKIM without DMARC - a technology looking for an algorithm to > which it can contribute.    Since nobody can articulate how a recipient uses > ARC information to reach an expected conclusion, something important is still > missing.    As I wrote in my last post, I think it fails to provide enough > information for a useful algorithm to be defined.    Even if that can be > solved, there are bigger problems.  We have no algorithm for a list to know if > a particular recipient uses ARC, or whether it will use the ARC information to > draw the desired conclusion about list messages.   Without those answers, > the list is doomed to continue From rewrite even if when it would not be > necessary.   And much of this is about AOL in particular, and the currently > available information suggests that AOL is not on board with ARC. I agree with the above analysis. I'd add that ARC is most useful to large sites that develop a global reputation system, as ARC allows to fine tune message attribution and thereby adjust the very computation of reputation. On the opposite, small sites may have problems trusting last hop's ARC data. They can still seal forwarded mail, though. As far as working around From: rewriting is concerned, given the premises quoted above, the only way is to reverse such rewriting upon final message delivery. Best Ale -- From nobody Sun Dec 6 05:40: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 C9AF63A0DBA for ; Sun, 6 Dec 2020 05:40:50 -0800 (PST) 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 UzGjyoCZEPdd for ; Sun, 6 Dec 2020 05:40:49 -0800 (PST) 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 4FE9C3A0DB5 for ; Sun, 6 Dec 2020 05:40:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1607262046; bh=i3kLiHLHE1zsM7SN6kU+i62KAbs+/co8y9LyEkC49j8=; l=821; h=To:References:From:Date:In-Reply-To; b=BQV1xS+xZSL1Lm0KPZDIHJuWWuzLMYpKq3/M+x2zH31zf4FFoiMtEzTdd0FryWnet JjT12RP1WkhBIyc0Y9w3l3VNpU1y0kbNJB9NtRaQxluFDdtVavq656GFt04HHOvxD5 zrK/kZf6oMGxvDWa5MNswwo1l7W3hslGny7kWgoIGtV/toEFJpL/ucNVdB9tA Authentication-Results: tana.it; auth=pass (details omitted) Original-From: Alessandro Vesely 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 00000000005DC03D.000000005FCCDF5E.00004826; Sun, 06 Dec 2020 14:40:46 +0100 To: dmarc@ietf.org References: <20201205231059.2BA23290EDCD@ary.qy> <7ae42764-176d-11a8-e084-b10b6f676944@mtcc.com> <8142f18c-ac79-1f94-97d1-2704f0b4ceb6@mtcc.com> <72d32b62-64fb-937a-dac5-6f4c5816f523@mtcc.com> From: Alessandro Vesely Message-ID: Date: Sun, 6 Dec 2020 14:40:46 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: <72d32b62-64fb-937a-dac5-6f4c5816f523@mtcc.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] ARC vs reject X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 06 Dec 2020 13:40:51 -0000 On Sun 06/Dec/2020 02:34:45 +0100 Michael Thomas wrote: >> >> 5) The work you and Alessandro have done with reverse transformation is more >> likely to produce a solution for the mailing lists.   The lists will continue >> to do From rewrite, but reverse-transform recipients can validate the true >> source of the message and restore the From if desired. > > I'm starting to get a little more serious about my quip that the MLM can insert > a sed script in a header to unmangle the message since it knows what transforms > it has done, unlike the receiving MTA trying to guess the common transformations. But then the receiving MTA will have to guess whether the sed script considerably alters the intended meaning of the message. For example, does it change a bank account number? Best Ale -- From nobody Sun Dec 6 05:58: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 0257E3A0DDF for ; Sun, 6 Dec 2020 05:58:04 -0800 (PST) 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 gO7PgvGv5y_7 for ; Sun, 6 Dec 2020 05:57:58 -0800 (PST) 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 E27623A0DD7 for ; Sun, 6 Dec 2020 05:57:57 -0800 (PST) Received: by mail-vk1-xa31.google.com with SMTP id w190so2461869vkg.13 for ; Sun, 06 Dec 2020 05:57:57 -0800 (PST) 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=d81OMYSULrcsveOyXA2H2zxZtFeaVZnxlNiihpAddb4=; b=KgCpRMtOwgtjP0sCAMSR2VK3Yk55jkXvwXPtb4KwA5dEPQjHGA5fP5sQ61duwGtwTJ RA9Kykru57lGiCOLPdmaSeHgWJ8ET76+OnZ+SCygUT1Yr+z8ROWf5FPGUONNlNCpCiR+ Rb3jHrub4guUcP/LcVTJ6Nen/if0raE6gy+PK/JWptOud6RzlxRMsNVnEkNvHnweySq9 sDRg5sfnENQG3b71TBMREUwc3VVJPkYHDOpm1UFIzWOu4ZtKvbnrv1+ADW02sSXe/Sye zLYTlIsOHpzV0sqnQvTudW+zsNXnzXM21wH+Eb+db2P9gwduoYwdjIJjYVlu7eNX3mkq ZzOg== 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=d81OMYSULrcsveOyXA2H2zxZtFeaVZnxlNiihpAddb4=; b=JoJZ1qEpbEWa/FNmbxejyjbj1g0LvMHwNHF3uAPTbqfB4sWY2FRBrJXZwmn51886Ol +J9k7NpP1tm2LC6bdvEEMJ/ONA9I+cUTRafM+rj8hQk3XiXnWGjugsKM9l1FxVRbTMOZ LBpAQtIT8GpLgJ0xTMEk1kDQL9WDd8F2HXYD75QBRats5Rj01NDVoyPcN14y6tD5Q58C wx+rWrpxxM5/M3qXO4ZGH9xiQ/qpEAKvPEWX/K7Ip8RATDkONZlIGWDQnv/xF8DLTbFO FrOOAf6/ix9XDxn2+yuQbliS+NLhlv8+uTATGdD+vFWmUjCBn2WcyEpW8hrjf+prb7Ox HF5Q== X-Gm-Message-State: AOAM533qUyensCfLlBQjQB42GBdbkHiSr8MdrK2AiOe4Jk+ULTEQWbcV PYWYm4NKR1fNS9sAUUxC6hU8gJbfD77b/5WWneoJu2QC X-Google-Smtp-Source: ABdhPJwdIxqFKuQup8SPQvEQ2s4G5sHxPcFnwEftXZLDFCivEiu8XlndPOf2vUkZYCpADC/4fsyqpIZAGyNGQvMAdHY= X-Received: by 2002:a1f:1b82:: with SMTP id b124mr10162651vkb.5.1607263076785; Sun, 06 Dec 2020 05:57:56 -0800 (PST) MIME-Version: 1.0 References: <134860ee-5fbf-2fb3-a5b3-4be68806ab22@mtcc.com> <7224575d-685f-5020-073e-c1880acecc88@mtcc.com> <7e459496-61f8-ddcd-713c-3b6be448090c@gmail.com> <2cecceac-1add-44ec-6e16-e157fee293fe@mtcc.com> <5a577765-4a0d-e1bf-5321-dfeff19d107e@gmail.com> <40d7e78e-7026-c65c-383c-df4e3c537de3@mtcc.com> <18e93db9-bde7-bf49-670c-1e680f2ce3a6@tana.it> <65bbc2a6-701a-1729-7892-ef68c1b6b237@mtcc.com> <5bce5710-6553-36ee-c46e-cbde702141e5@tana.it> In-Reply-To: <5bce5710-6553-36ee-c46e-cbde702141e5@tana.it> From: "Murray S. Kucherawy" Date: Sun, 6 Dec 2020 05:57:43 -0800 Message-ID: To: Alessandro Vesely Cc: IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000c0a1a505b5cc186c" Archived-At: Subject: Re: [dmarc-ietf] is DMARC informational? X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 06 Dec 2020 13:58:04 -0000 --000000000000c0a1a505b5cc186c Content-Type: text/plain; charset="UTF-8" On Sun, Dec 6, 2020 at 5:09 AM Alessandro Vesely wrote: > On chartering the WG in 2013, the decision was made to publish DMARC as > independent submission, even though it was going to be discussed and reach > consensus of a IETF WG. AIUI, that was the original question of this > thread. > This isn't correct. DMARC was not published as a product of this working group. It was published through the Independent Submission stream, which can only produce Informational documents. At the time, this was because the group advancing DMARC wanted to preserve the installed base and not cede change control to the IETF, so a working group was not an option. The working group and the ISE submission started their journies almost at the same time, but they were procedurally independent. -MSK, ART AD --000000000000c0a1a505b5cc186c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sun, Dec 6, 2020 at 5:09 AM Alessandro= Vesely <vesely@tana.it> wrote:=
On chartering the WG in 2013, the decision was made to publish = DMARC as
independent submission, even though it was going to be discussed and reach =
consensus of a IETF WG.=C2=A0 AIUI, that was the original question of this = thread.

This isn't correct.=C2=A0 D= MARC was not published as a product of this working group.=C2=A0 It was pub= lished through the Independent Submission stream, which can only produce In= formational documents.=C2=A0 At the time, this was because the group advanc= ing DMARC wanted to preserve the installed base and not cede change control= to the IETF, so a working group was not an option.

The working group and the ISE submission started their journies almost at= the same time, but they were procedurally independent.

-MSK, ART AD
--000000000000c0a1a505b5cc186c-- From nobody Sun Dec 6 06:06: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 9E06A3A0DFF for ; Sun, 6 Dec 2020 06:06:52 -0800 (PST) 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 XbcCw45qnLHy for ; Sun, 6 Dec 2020 06:06:51 -0800 (PST) Received: from mail-pl1-x636.google.com (mail-pl1-x636.google.com [IPv6:2607:f8b0:4864:20::636]) (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 DCCB93A0DF9 for ; Sun, 6 Dec 2020 06:06:50 -0800 (PST) Received: by mail-pl1-x636.google.com with SMTP id bj5so5751761plb.4 for ; Sun, 06 Dec 2020 06:06:50 -0800 (PST) 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=mM++UV9noYmd/YaOigYcANUR05KZvS0XmjNvBREocDI=; b=lcJOJd+Y8g7wcvPkD8vDTGFmlQZmoy5ElWG1lCv3t+UWDeAi/6v1+cqFf55w20QNCg BncBEISERUDTTmFGm6b7ktNgIwVSAieUfiM7vmIbXdeXUVaxTCmabdjgBTWiLPH+/KNo 9dTYOy1xFK3Iq17vogKOg8VmRVxamdQhHlSBg1RsZvAMYGF9oEiV55LJfLYtW8+0Zi1J 338ZxeDRffKMhh5e2HgHSKjY7HZtHsl9iIZeB84zAJPyMjZo5IMMNSTEQR5ZtDyr9oGy U8m5pYor3TIL9kW1aW57qXp3ULiFh6oJbOU6f2WPcAXedc9snVPw+IZod2kEMgIAavoO 22yQ== 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=mM++UV9noYmd/YaOigYcANUR05KZvS0XmjNvBREocDI=; b=IfvAUn/Gm8SZp+cmgTSkBhhU72SMlC0wDXr2Xo4wkfdBZN/T1QQYnq6B63GHJiABSl Al7ypirA2zhMDE71TOxKCiqF5YCSKusOpOLS6yr1L4nT+ZjwoR9CSSP0uYhtzihzxdo+ 5rKWX7MYcE51bZaxB8wTlG4w/U97noKDVofvl6qOgWdFgolDb7vsV54gpFjmrhQNNGBA AduThRbvSRNcjAbvqakKhn4Ge5Oi8jNggw8IEm0/xWvNIJosEeiQRnJFM8gGi7oQP4Hf RfM6dD4ZiQBRhIam4kWcSLw1I58KmYnswIl+HRWGETgSjJOQ9fibrfHfPJ+hVmPavd36 hIBQ== X-Gm-Message-State: AOAM530wqYsbX9SMeeDcR/DomSGEQTCBOyWcUaJcAErNo9UhMsfEqPrJ wF4QcSOqdpQVYr4q5pdEINOJTxabXh4= X-Google-Smtp-Source: ABdhPJxMlXH2jaucMg+aAa2F/Bjyq8d6SV2pBthrY8Rg+uvYH5MPftwX6B4EBHM1fBNUiEV7vKnqYA== X-Received: by 2002:a17:902:6a87:b029:da:e253:dd6a with SMTP id n7-20020a1709026a87b02900dae253dd6amr5620455plk.81.1607263609965; Sun, 06 Dec 2020 06:06:49 -0800 (PST) Received: from [192.168.0.109] (c-24-130-62-181.hsd1.ca.comcast.net. [24.130.62.181]) by smtp.gmail.com with ESMTPSA id z25sm9418301pge.66.2020.12.06.06.06.49 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 06 Dec 2020 06:06:49 -0800 (PST) To: "Murray S. Kucherawy" Cc: IETF DMARC WG References: <134860ee-5fbf-2fb3-a5b3-4be68806ab22@mtcc.com> <7224575d-685f-5020-073e-c1880acecc88@mtcc.com> <7e459496-61f8-ddcd-713c-3b6be448090c@gmail.com> <2cecceac-1add-44ec-6e16-e157fee293fe@mtcc.com> <5a577765-4a0d-e1bf-5321-dfeff19d107e@gmail.com> <40d7e78e-7026-c65c-383c-df4e3c537de3@mtcc.com> <18e93db9-bde7-bf49-670c-1e680f2ce3a6@tana.it> <65bbc2a6-701a-1729-7892-ef68c1b6b237@mtcc.com> <5bce5710-6553-36ee-c46e-cbde702141e5@tana.it> From: Dave Crocker Message-ID: <6b53359c-150a-10a3-75ff-3e1a157ea822@gmail.com> Date: Sun, 6 Dec 2020 06:06:47 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] is DMARC informational? X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 06 Dec 2020 14:06:53 -0000 On 12/6/2020 5:57 AM, Murray S. Kucherawy wrote: > It was published through the Independent Submission stream, which can > only produce Informational documents. Since this is the IETF and being picky is de rigueur, I'll note that the Independent stream also permits Experimental... You're welcome.  No need to thank me. d/ -- Dave Crocker dcrocker@gmail.com 408.329.0791 Volunteer, Silicon Valley Chapter American Red Cross dave.crocker2@redcross.org From nobody Sun Dec 6 07:13: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 179523A0E65 for ; Sun, 6 Dec 2020 07:13:14 -0800 (PST) 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 ujXoIfaPl4rc for ; Sun, 6 Dec 2020 07:13:12 -0800 (PST) Received: from mail-qt1-x82b.google.com (mail-qt1-x82b.google.com [IPv6:2607:f8b0:4864:20::82b]) (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 3802E3A0E63 for ; Sun, 6 Dec 2020 07:13:12 -0800 (PST) Received: by mail-qt1-x82b.google.com with SMTP id b9so7652314qtr.2 for ; Sun, 06 Dec 2020 07:13:12 -0800 (PST) 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=h3EShmcXdc7+b9S8MYthbbT0wfOFnBllhBuIJaPIpUw=; b=ScNu3bviaw99pR4gV7Ord6ZTZikPy8JF0Qt3D/AzxnYypmH3FVFT5uohYzA7A93SkR oLA7V+EAH3iJ0KZh7CyLIUzJlWm5Icyn+uf2jax739R111LJwURFT0VvXq8mQFNKHLn2 QT8sh9qNtHfFawPQhmoCFW1+lY8K9tPr288elffsZ+DIVvzA+v0Z+EpurM6OcO9TxQ72 wCgTdOyEbd0kyRJmPKTvJByyqWXXP0N0z7YDU7ZAqM+RF3dIVu03XpJxosfzuESZYh49 kJBoUdyWclIbk4P8PMfwRYrzNxsp6xC9RbJSqyn1NPwyAezbAT8+Zun63uQ1YMbFuh3Y Ygzg== 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=h3EShmcXdc7+b9S8MYthbbT0wfOFnBllhBuIJaPIpUw=; b=osH/aCFIOxgq8ve8cRHKtXr3xVTzJ+efKcXiAksaeIvw9AFjwU6eYrW/srHaai95aI f2rjhs8ONxLc5KQt1o55gtWew0fkBa4pm/MQgPJIMsVl/ZIV6qFuk4hQJGHbfCqYf4GP K1ROemW2FbZMam+If+SlE3wfU73RSS7CRSry9+GkgKCOQ4btUwCe2oLFWKEWDmvJNAjs 2thR4HWcA/6ZCPH+YM+9t4UvWdnIp0TZZbS90TBUOul2cEA/hYw6Hvvqlxqe2PEZ3xI+ 3NhXIWuZyHz/Y6a/j0CG+GrLtRgYAsUSFwc0AXb1X1wIpkUk4zAoh85xy5gS26VYf98n d+NA== X-Gm-Message-State: AOAM532rcxoRCmoKKAxmKYyoogMjc1rtwRBIYrecfjiresIaKCoSJ8IS L+cRBSFhb9sAnbCSwkIzIpcFhZo3hJqNyrXar8g= X-Google-Smtp-Source: ABdhPJzCCtgcnhGEqnJw6ZUQC8mKFpw/so3qyjLYtJXVWAwjJc9oj+f0r3OdZSQfHCM5yPCUzgjZwbeuYB2nU9V3Bfk= X-Received: by 2002:ac8:5c05:: with SMTP id i5mr19282500qti.34.1607267591145; Sun, 06 Dec 2020 07:13:11 -0800 (PST) MIME-Version: 1.0 References: <134860ee-5fbf-2fb3-a5b3-4be68806ab22@mtcc.com> <7224575d-685f-5020-073e-c1880acecc88@mtcc.com> <7e459496-61f8-ddcd-713c-3b6be448090c@gmail.com> <2cecceac-1add-44ec-6e16-e157fee293fe@mtcc.com> <5a577765-4a0d-e1bf-5321-dfeff19d107e@gmail.com> <40d7e78e-7026-c65c-383c-df4e3c537de3@mtcc.com> <18e93db9-bde7-bf49-670c-1e680f2ce3a6@tana.it> <65bbc2a6-701a-1729-7892-ef68c1b6b237@mtcc.com> <5bce5710-6553-36ee-c46e-cbde702141e5@tana.it> In-Reply-To: From: Dotzero Date: Sun, 6 Dec 2020 10:13:00 -0500 Message-ID: To: "Murray S. Kucherawy" Cc: Alessandro Vesely , IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000d44d4305b5cd2594" Archived-At: Subject: Re: [dmarc-ietf] is DMARC informational? X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 06 Dec 2020 15:13:14 -0000 --000000000000d44d4305b5cd2594 Content-Type: text/plain; charset="UTF-8" On Sun, Dec 6, 2020 at 8:58 AM Murray S. Kucherawy wrote: > On Sun, Dec 6, 2020 at 5:09 AM Alessandro Vesely wrote: > >> On chartering the WG in 2013, the decision was made to publish DMARC as >> independent submission, even though it was going to be discussed and >> reach >> consensus of a IETF WG. AIUI, that was the original question of this >> thread. >> > > This isn't correct. DMARC was not published as a product of this working > group. It was published through the Independent Submission stream, which > can only produce Informational documents. At the time, this was because > the group advancing DMARC wanted to preserve the installed base and not > cede change control to the IETF, so a working group was not an option. > Murray, your recollection isn't quite accurate. The group advancing DMARC was looking to preserve the installed base for a defined period of time due to a) almost all the implementations were custom code and b) there was a desire to see more experience in the wild as almost all of the deployments were by members of the group advancing DMARC. There was also a political element in that there were folks within IETF that felt the DMARC folks were only looking for a rubber stamp, nothing more. This resulted in part of the pushback. > > The working group and the ISE submission started their journies almost at > the same time, but they were procedurally independent. > There isn't a whole lot of procedure for ISE. Given the speed of the working group, in retrospect there wasn't much risk of changes impacting the installed base for a period much longer than what the DMARC group folks were looking for. Just saying. Michael Hammer --000000000000d44d4305b5cd2594 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Sun, Dec 6, 2020 at 8:58 AM Murray= S. Kucherawy <superuser@gmail.co= m> wrote:
On Sun, Dec 6, 2020 at 5:09 AM Alessandr= o Vesely <vesely@tan= a.it> wrote:
On chartering the WG in 2013, the decision= was made to publish DMARC as
independent submission, even though it was going to be discussed and reach =
consensus of a IETF WG.=C2=A0 AIUI, that was the original question of this = thread.

This isn't correct.=C2=A0 D= MARC was not published as a product of this working group.=C2=A0 It was pub= lished through the Independent Submission stream, which can only produce In= formational documents.=C2=A0 At the time, this was because the group advanc= ing DMARC wanted to preserve the installed base and not cede change control= to the IETF, so a working group was not an option.

Murray, your recollection isn't quite accura= te. The group advancing DMARC was looking to preserve the installed base fo= r a defined period of time due to a) almost all the implementations were cu= stom code and b) there was a desire to see more experience in the wild as a= lmost all of the deployments were by members of the group advancing DMARC. = There was also a political element in that there were folks within IETF tha= t felt the DMARC folks were only looking for a rubber stamp, nothing more. = This resulted in part of the pushback.
The working group and the ISE submission started their journie= s almost at the same time, but they were procedurally independent.

There isn't a whole lot of pr= ocedure for ISE. Given the speed of the working group, in retrospect there = wasn't much risk of changes impacting the installed base for a period m= uch longer than what the DMARC group folks were looking for. Just saying.

Michael Hammer
--000000000000d44d4305b5cd2594-- From nobody Sun Dec 6 07:23: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 23EF03A0E7F for ; Sun, 6 Dec 2020 07:23:46 -0800 (PST) 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 j9ZiOXkLKINz for ; Sun, 6 Dec 2020 07:23:44 -0800 (PST) Received: from mail-pl1-x633.google.com (mail-pl1-x633.google.com [IPv6:2607:f8b0:4864:20::633]) (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 BAA433A0E85 for ; Sun, 6 Dec 2020 07:23:44 -0800 (PST) Received: by mail-pl1-x633.google.com with SMTP id 4so5806290plk.5 for ; Sun, 06 Dec 2020 07:23:44 -0800 (PST) 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=QP73IBvu/2LuS9n9cNtCdYcuaf776SLBDHP4r2btoF0=; b=ivB9RO33OgWb/VUvNpEgOwXoKgxs+/+nLAeyhHomCXJ7WTxhVw56IJE+DiFsXSH8hh wWiq+QG+/U3J5/PXRFsk5bXG1Ya+9xrINGUPORjDoe2DTa1ehoxAJISQBbBHjPM58kdk WccAqMiisGuKYxOATb36rUehylIEcZe2a5YB+cD5Z2G+iAdnrQXRv9tvuRoIWLC69FqJ Z2H3m9JuzwXzCYLyyItIzUJzvdzYcd5b33qMIBF71BH9CqczsyoXHyHdGxFM2vpLc8L2 jMcyZr3ueWPlhUdJrnW1C+x8zgQyphsEnjeH64ioX6ogVxH6sKDwjKH6LzQ8Of7z/8oH G4qA== 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=QP73IBvu/2LuS9n9cNtCdYcuaf776SLBDHP4r2btoF0=; b=VY+0aJZAtkJfJoP5zyzQ8smKWs62ab/0KzWuRj9Z3Ntar45M4XTumPcpJfRRclfBN5 OVyUOMvUvPXAZ1ZLuwc+B+YAD2PbNW7Cd6JeusWUazB0CSbsqfXJ1qMmcnp6mPpsFeQO J0VARbC0wUyelhWVNMEVTCk9pzIX3NqAoPSN9wXCa7nrTZJjTryIOs2UDKAgokhoP6Ru lYx1JH3n/IjIlf/4xmRQM2y5ZCtReCjk5kWHrrBm0DOa/Ov/sHiEJgUaCcjaPMoTKnUK 8OZmN5G0hkgM/Tu+mmjoHCOtzNntWZAhHuTAEphaJgfawedBTd1Z1EJAHlaK5ZBvW57X ucyQ== X-Gm-Message-State: AOAM533LNBIjKveMEWwQ1RSC4Jky6/wYKvg0GGnZN99y3MZaF6ozYycf fEyCA4joSvlWlxhtr/ZEjoxnotBsd0Y= X-Google-Smtp-Source: ABdhPJw8LA+ESVLFxZcVZNFkRhlUxT48vN+kDci68zVjWT1xLf5Q/GZgOb/pjqvtQaz83yQsDaMA5w== X-Received: by 2002:a17:90a:e551:: with SMTP id ei17mr12632279pjb.187.1607268223635; Sun, 06 Dec 2020 07:23:43 -0800 (PST) Received: from [192.168.0.109] (c-24-130-62-181.hsd1.ca.comcast.net. [24.130.62.181]) by smtp.gmail.com with ESMTPSA id b8sm9880078pgk.7.2020.12.06.07.23.42 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 06 Dec 2020 07:23:43 -0800 (PST) To: dmarc@ietf.org References: <134860ee-5fbf-2fb3-a5b3-4be68806ab22@mtcc.com> <7224575d-685f-5020-073e-c1880acecc88@mtcc.com> <7e459496-61f8-ddcd-713c-3b6be448090c@gmail.com> <2cecceac-1add-44ec-6e16-e157fee293fe@mtcc.com> <5a577765-4a0d-e1bf-5321-dfeff19d107e@gmail.com> <40d7e78e-7026-c65c-383c-df4e3c537de3@mtcc.com> <18e93db9-bde7-bf49-670c-1e680f2ce3a6@tana.it> <65bbc2a6-701a-1729-7892-ef68c1b6b237@mtcc.com> <5bce5710-6553-36ee-c46e-cbde702141e5@tana.it> From: Dave Crocker Message-ID: <8961245c-4d0f-a39a-066b-7d8e96e8468d@gmail.com> Date: Sun, 6 Dec 2020 07:23:40 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] is DMARC informational? X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 06 Dec 2020 15:23:46 -0000 On 12/6/2020 7:13 AM, Dotzero wrote: > The group advancing DMARC was looking to preserve the installed base > for a defined period of time Work that comes to the IETF often has a significant history before that, often including a well-developed specification and significant installed base. It is not uncommon to publish that pre-IETF specification as an RFC, to establish the formal background for the prior work. That's what was done for DMARC. The political -- and, IMO, technical -- issues at the time merely served to delay seeking standards track for a revised specification, which is what is now being pursued.  While this amount of delay is unusual, the sequence is not. d/ -- Dave Crocker dcrocker@gmail.com 408.329.0791 Volunteer, Silicon Valley Chapter American Red Cross dave.crocker2@redcross.org From nobody Sun Dec 6 08:41: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 C0F283A0FCB for ; Sun, 6 Dec 2020 08:41:14 -0800 (PST) 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 (2048-bit key) header.d=iecc.com header.b=iVC0ud2i; dkim=pass (2048-bit key) header.d=taugh.com header.b=TO83kQOI Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YfgMYJJPzEHN for ; Sun, 6 Dec 2020 08:41:13 -0800 (PST) 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 A58AA3A0FC9 for ; Sun, 6 Dec 2020 08:41:11 -0800 (PST) Received: (qmail 32383 invoked from network); 6 Dec 2020 16:41:09 -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=7e1f.5fcd09a5.k2012; i=johnl-iecc.com@submit.iecc.com; bh=IXDmgcVdqDZc22kYzYRUaOK992eeVNmpARNPQP+IWh0=; b=iVC0ud2iviyO7Gu9V8afFpT1csazbMtsM9LFKfMJZhFFlDwiBftYm0b0Vph8ra4COVoz8tpiH10FdMYxtvWenE/ggzADq3pW1SDCjsZmsj1eNkR+15FMRStAV8dqpmz7GBfZ7sa3Hv1pb1tjr38wb1A/mFTue8aObBz1VhdHmHTN05pCWHPTYMGXblYiZ4sN3lkT1UhcA4DWL7MHLNaPOvfqrMm5VSGTTt/W0igVsYJTCqY97bpXAb87AydI5v/gbtgajUIByuXg+wChrIWnFFp8YIDwD7TDAJbwIaGukwhBDMGS0XhjMFhsvmPKHVupTkhUBrtjE1WC4UhBII/ooA== 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=7e1f.5fcd09a5.k2012; olt=johnl-iecc.com@submit.iecc.com; bh=IXDmgcVdqDZc22kYzYRUaOK992eeVNmpARNPQP+IWh0=; b=TO83kQOIAHDnUZoskS00Wv9Dq6b4LRyR1Vnpc2SilG6QB9MRCcioTPh1LAUtpF6Br2Lvzj+9IJPg2oYGFIc3HLPq1hsrrI4xMYmIC9XQtyOtSiR0/Ogav7P4MgBTQuymgJ/SBT4Blkrh7k+d5oDRDOx9swSkNK4aNHcuXIWjk9Fy6+3Q2+A2Z/FdYe5Nz3QwHBLVsqIOHJSAi6AiGjKbAS5r72g4IllzjQ1kq18uiZEX17y1TtkWz7LbFL0lnaNyj84Waj8f2v1D/ed1Qsm9uU1xeez5ifHn4mREj8DyTsecmpyNba8j+VKfdP85t3ABb0faXUsfawm0/C962rtlEg== 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 Dec 2020 16:41:09 -0000 Date: 6 Dec 2020 11:41:09 -0500 Message-ID: <144b4971-f276-b29-8ea4-45fd24a7a59e@taugh.com> From: "John R Levine" To: "Alessandro Vesely" , dmarc@ietf.org In-Reply-To: <570ba614-a138-8a83-eae1-e6077b82937f@tana.it> References: <20201205210639.54261290454A@ary.qy> <570ba614-a138-8a83-eae1-e6077b82937f@tana.it> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [dmarc-ietf] Ticket #42 - Expand DMARC reporting URI functionality X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 06 Dec 2020 16:41:15 -0000 >> If we want to do something like that, I would overload the existing >> !size hack. For example, add an "f" for finished flag and say that the >> URIs are conceptually processed from left to right and if you send >> your report to one with a !f (or !10mf or the like) flag, you can stop. > > Legacy producers unable to interpret "f" may discard the whole URI. At this point we're both just guessing what current code might do with syntax errors in a rua= tag. Here's something that's definitely compatible: We add a new ruap= tag for rua preferred, with the same syntax as rua. If the reporting system can handle all of the URIs in the ruap tag, it uses them. (They don't all have to successfully deliver, but it knows how to try.) Otherwise it falls back to rua. The goal here is that someone can put the new https: URI in ruap and the old mailto: URI in rua. To send a report using the https: URI, the reporter appends the filename described in section 7.2.1.1 to the given URI and does a PUT of the report, with MIME type application/gzip if it's compressed an text/xml if not. The server responds with code 201 if the report is succesfully stored. It'd be something like this if the URI is https://report.bar.com/dmarc/ PUT https://report.bar.com/dmarc/foo.com%21bar.com%211607068800%211607155200.xml.gz Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From nobody Sun Dec 6 09: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 377B53A0114 for ; Sun, 6 Dec 2020 09:01:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.652 X-Spam-Level: X-Spam-Status: No, score=-1.652 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mtcc-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DaLOXwYjaT2m for ; Sun, 6 Dec 2020 09:01:07 -0800 (PST) Received: from mail-pj1-x102d.google.com (mail-pj1-x102d.google.com [IPv6:2607:f8b0:4864:20::102d]) (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 574593A00D8 for ; Sun, 6 Dec 2020 09:01:07 -0800 (PST) Received: by mail-pj1-x102d.google.com with SMTP id h7so5836924pjk.1 for ; Sun, 06 Dec 2020 09:01:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mtcc-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=BSKLEMgNm1ZUBqix+eivUnJ+59tRpSDdGFRzQjEnBdU=; b=BuXSKBpp6kH6ZYsTimpZMHqpFUGY5FIYdCYuN6aP6z2hswdnpmH4gknIVW9DVZnk7i GCGXE76mGQzaibm0I2092GjOkGW2ny40TlR+qsLPZYV8lsD52IE//Sta+5VhKg5LJizZ ihHaUJmcnoW9yb5jI8bMRCGtJKLtxnjhnMCig4j/eH1+jkD72g8GGsRVHhm9V/5y2brV 2PfPy6moVIzbnRtdMTFFBgV0IDVG30CMsd+mKb0FDPJHTEZCde9HHMslUixoBcUrZeaM AEQWZvQp9QJDhpqpaYmjApZxdQAQjVW3Cfi+k9UW+aDuTYsRpWBmAj2W5QP1wbjEGvmP /Qew== 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=BSKLEMgNm1ZUBqix+eivUnJ+59tRpSDdGFRzQjEnBdU=; b=HkA7gxWwdug6NhJJFwxQR2Ms2tVaV5It9csopfYDyhsnjR3607cKzR8ce8vsuuHjbE m/2mimf6gwHJaT/a0TgIPSKOFK+gH6JMS5MDpqSV4caO9SvMKga8Yj6HT0pxawr8W29r z/cFPeXCEgGjs0RMlyJi+ZSbh7OJ6bJvlJNKVzpX4tgA0ViAZ5PUcAk9nbAP1lqS6L1N tklfQJrbQhkDxF5+hNORf2h/UrZ9Ie5N0okyhZnEoV2UiuRaXC1EmMUc+kvKWObgOyQh 7LRHZfRVRZu+aMxyYk2PHKErtm/zGe4/itB/l1vZf5CW2+lOMXWZO81JXNYH1hucXscu 31xQ== X-Gm-Message-State: AOAM5330Onn9aoK4LJ4qdnJbw357JvLiNhYKbMgitG0eOOosPO5KMVp7 6+coPcmHeYtVXCebAZYGcfnJ0pdqUCyXLQ== X-Google-Smtp-Source: ABdhPJxWh0VUGKieGxUeUvs+KXPXAkDiHSTFr9AFRv+2Bsaw+WdlYxmBdXZ+3FevtPCKAu0da5Gadg== X-Received: by 2002:a17:902:8c8a:b029:d6:d1e7:e78e with SMTP id t10-20020a1709028c8ab02900d6d1e7e78emr12438866plo.39.1607274066260; Sun, 06 Dec 2020 09:01:06 -0800 (PST) Received: from mike-mac.lan (107-182-42-33.volcanocom.com. [107.182.42.33]) by smtp.gmail.com with ESMTPSA id d2sm1608536pjd.29.2020.12.06.09.01.05 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 06 Dec 2020 09:01:05 -0800 (PST) To: dmarc@ietf.org References: <20201205231059.2BA23290EDCD@ary.qy> <7ae42764-176d-11a8-e084-b10b6f676944@mtcc.com> <8142f18c-ac79-1f94-97d1-2704f0b4ceb6@mtcc.com> <72d32b62-64fb-937a-dac5-6f4c5816f523@mtcc.com> From: Michael Thomas Message-ID: Date: Sun, 6 Dec 2020 09:01:04 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.5.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] ARC vs reject X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 06 Dec 2020 17:01:12 -0000 On 12/6/20 5:40 AM, Alessandro Vesely wrote: > On Sun 06/Dec/2020 02:34:45 +0100 Michael Thomas wrote: >>> >>> 5) The work you and Alessandro have done with reverse transformation >>> is more likely to produce a solution for the mailing lists.   The >>> lists will continue to do From rewrite, but reverse-transform >>> recipients can validate the true source of the message and restore >>> the From if desired. >> >> I'm starting to get a little more serious about my quip that the MLM >> can insert a sed script in a header to unmangle the message since it >> knows what transforms it has done, unlike the receiving MTA trying to >> guess the common transformations. > > > But then the receiving MTA will have to guess whether the sed script > considerably alters the intended meaning of the message. For example, > does it change a bank account number? > This actually highlights why my observation is correct. If the intermediary showed how to reverse their changes perfectly to be able to validate the original signature, it says nothing about whether those changes to be delivered to the recipient are acceptable to the originating domain. for the case of a bank sending me sensitive mail, the answer is that it is never ok. for somebody working on internet standards working on ietf lists, the answer is that it is fine. hence trying to get two states of the one "reject" is insufficient. Mike From nobody Sun Dec 6 09:06: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 66B2D3A02C1 for ; Sun, 6 Dec 2020 09:06:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.65 X-Spam-Level: X-Spam-Status: No, score=-1.65 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, 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=mtcc-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4OWa1Y5h4GAE for ; Sun, 6 Dec 2020 09:06:48 -0800 (PST) Received: from mail-pg1-x534.google.com (mail-pg1-x534.google.com [IPv6:2607:f8b0:4864:20::534]) (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 1528C3A02BC for ; Sun, 6 Dec 2020 09:06:47 -0800 (PST) Received: by mail-pg1-x534.google.com with SMTP id w4so6794482pgg.13 for ; Sun, 06 Dec 2020 09:06:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mtcc-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=2SC/bGTMVVmhjIV9WfmgJlWS9BtkKiyT0msJsbJhfDY=; b=Esb7siPR8XosdTIDOrxO2uP9qWfbaJdNZTT7kJ0ZnoLboVj3TzB6QWvzrFsZUrut1d 3efB/vTLOb3uRNEG5X8o0g96g+J9BYRZ2Ant5mhWJ8jMvZHj8WHb046XmhA/AOm3wkSI B8ru/Kh2l+EPAJc4VYjwV4RN9cAeE6cGIamO+/kPkXZKvf5/spMpCA8DC0/4qmXKRT4U Zfwo5BmrvXSTzEgiV6pPNWz850eOTidwrOiSslvhHPEaDsuaWK00gI5QyAo+q0AKrVqN CXNAjcWacw7R8xiV/0BOfRNpVdYb14Q0JHzURmK246dBMfI5i1PFeNMQlXGi4HpXyfoi mUYA== 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=2SC/bGTMVVmhjIV9WfmgJlWS9BtkKiyT0msJsbJhfDY=; b=RgpNHzSY3xmTaH6+alu4CAgtao/soO8hwvXBEFe4RNRBIidJpvxDIaGkZRX+gbn97W RfMtJ3gS5vZs8fWXCTf4uO63pG5G0FVAYZlAa4Efo/XrNVwFbZ/kYgN+JGNZEYVlGoru ew5IvHcirdbxGqWihRArbQzp1Lz7MLW+BKnb3ld3ciJIZfD5RNCxsf8N0wTFT311SCaZ cXECTZRXDuX1FzdGlamJp0kVIgQD+x0slAAxEC13H3HsnrpSNiCmrr4n3lPtdi1lDx33 RUW7S9av/M3CquImtBPYiMJ7Jh62mjFE3x27penh1sIF+YvKVPtenKfXxHF7SK42tL+e V0Bg== X-Gm-Message-State: AOAM530xTofCbZs0YdjMQ7bUqLyhacqtxCuhzx/7Z1Houi51jTRjHsvz 9Qc5MijZoqUYjDWRKyxQHiv8QiwgqXVoLg== X-Google-Smtp-Source: ABdhPJzt/3SwCBXyLv4rGaoV2/GQ4n9/9dUETE9PR5CunXhNh8WKm6i+ZT1jYQBZKqKqr/IFii2OPg== X-Received: by 2002:a65:63da:: with SMTP id n26mr15232699pgv.306.1607274406662; Sun, 06 Dec 2020 09:06:46 -0800 (PST) Received: from mike-mac.lan (107-182-42-33.volcanocom.com. [107.182.42.33]) by smtp.gmail.com with ESMTPSA id q7sm11252489pfh.91.2020.12.06.09.06.45 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 06 Dec 2020 09:06:46 -0800 (PST) To: dmarc@ietf.org References: <134860ee-5fbf-2fb3-a5b3-4be68806ab22@mtcc.com> <7224575d-685f-5020-073e-c1880acecc88@mtcc.com> <7e459496-61f8-ddcd-713c-3b6be448090c@gmail.com> <2cecceac-1add-44ec-6e16-e157fee293fe@mtcc.com> <5a577765-4a0d-e1bf-5321-dfeff19d107e@gmail.com> <40d7e78e-7026-c65c-383c-df4e3c537de3@mtcc.com> <18e93db9-bde7-bf49-670c-1e680f2ce3a6@tana.it> <65bbc2a6-701a-1729-7892-ef68c1b6b237@mtcc.com> <5bce5710-6553-36ee-c46e-cbde702141e5@tana.it> From: Michael Thomas Message-ID: <7d8e0e8c-2186-e1ff-c72e-01131ba09e08@mtcc.com> Date: Sun, 6 Dec 2020 09:06:44 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------59673F3F6EAA8B7BC9C0F5EE" Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] is DMARC informational? X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 06 Dec 2020 17:06:49 -0000 This is a multi-part message in MIME format. --------------59673F3F6EAA8B7BC9C0F5EE Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 12/6/20 5:57 AM, Murray S. Kucherawy wrote: > On Sun, Dec 6, 2020 at 5:09 AM Alessandro Vesely > wrote: > > On chartering the WG in 2013, the decision was made to publish > DMARC as > independent submission, even though it was going to be discussed > and reach > consensus of a IETF WG.  AIUI, that was the original question of > this thread. > > > This isn't correct.  DMARC was not published as a product of this > working group.  It was published through the Independent Submission > stream, which can only produce Informational documents.  At the time, > this was because the group advancing DMARC wanted to preserve the > installed base and not cede change control to the IETF, so a working > group was not an option. > > The working group and the ISE submission started their journies almost > at the same time, but they were procedurally independent. > Would that these two responses been the only replies to my question. Mike --------------59673F3F6EAA8B7BC9C0F5EE Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit


On 12/6/20 5:57 AM, Murray S. Kucherawy wrote:
On Sun, Dec 6, 2020 at 5:09 AM Alessandro Vesely <vesely@tana.it> wrote:
On chartering the WG in 2013, the decision was made to publish DMARC as
independent submission, even though it was going to be discussed and reach
consensus of a IETF WG.  AIUI, that was the original question of this thread.

This isn't correct.  DMARC was not published as a product of this working group.  It was published through the Independent Submission stream, which can only produce Informational documents.  At the time, this was because the group advancing DMARC wanted to preserve the installed base and not cede change control to the IETF, so a working group was not an option.

The working group and the ISE submission started their journies almost at the same time, but they were procedurally independent.


Would that these two responses been the only replies to my question.

Mike

--------------59673F3F6EAA8B7BC9C0F5EE-- From nobody Sun Dec 6 09:10:32 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B9243A040B for ; Sun, 6 Dec 2020 09:10:30 -0800 (PST) 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 OImAXZuWXaWY for ; Sun, 6 Dec 2020 09:10:29 -0800 (PST) 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 2A5F03A03FC for ; Sun, 6 Dec 2020 09:10:28 -0800 (PST) Received: by mail-pg1-x52d.google.com with SMTP id i38so6829812pgb.5 for ; Sun, 06 Dec 2020 09:10:28 -0800 (PST) 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=oH3ZUA24D/WtMB8Q12MkzLAWmtgf8AKQRZrxxIGgAkQ=; b=Qd1M7VJxvZUFlVZNqbg+OzBitKg7ljyu8FAskyVqa/sHItRdqabKZOm2rwyIC0CDrW KtRpA4YxugbPLZkTJEiCRSpavObi/ikINMUnQuWX4FITSKuCPdq4uEpeTP9OdkK4eNbd bAbEODI+c2mR3epPDxPAhycTt5jLyDhR4QpaXJe9qr8ea8WdNqQuPCMcyypQPfTp7pmX y5R+GmREM+BYxkDstBWxnygHabfu+05QuL9u2xmDqIwtrS0WxdZzISbv3xFzBxiCk98E on2UeWzxHmtLBAo6BLjvJy7C/by+q3Rub6tZZCd04FpYb/4oHkkCDyWHTVQOv9RX4eJm ThzQ== 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=oH3ZUA24D/WtMB8Q12MkzLAWmtgf8AKQRZrxxIGgAkQ=; b=WP+vlC09QaQTlbP2qlEEPoTRfY9F4cxMV8psMN+K22iYSwU9x+IMA1zArCYojEtTmy dbf5Bag5b85dkiGfI/rOknkMFtlFF2GyaozCL5enbh6GV2ZSqL3A1DRvhCXgIkDGVmBO rrh9N6xCd6gLzmWRv7NAY/iX3S40Ssh/ox6lv1z5IFPfcQn5cQJfjCjSx5QZVhaNgVoj BMgLDD47QEBS+2fN8Q03PbvotYLdo+OwOiX5NvxumKt7pJ9u7AYpU4vr204mOwqfF4Md QaCfYAfvWSfeM8YGKcFS4pSJv6NEo96ZvrY0IinqxMKQpJ6f2Srgfa9JuOcjN3O6gXeN 0lBQ== X-Gm-Message-State: AOAM532eJ27wV/162qy+/8KREavgdVQsZjCzgZrarb9UMzrFGHlX3fTN YSetlbfywFR1iPqqa9j5FQrWuuJ4qvM= X-Google-Smtp-Source: ABdhPJwYYEpsQh3mjr8TXW3j1UC1sKvX+idGFnVMjYBkYVzBi8AUv4d8waK8XUrCNA5sDBKM/pe/WA== X-Received: by 2002:a62:d152:0:b029:19d:cf97:5242 with SMTP id t18-20020a62d1520000b029019dcf975242mr7302725pfl.28.1607274628223; Sun, 06 Dec 2020 09:10:28 -0800 (PST) Received: from [192.168.0.109] (c-24-130-62-181.hsd1.ca.comcast.net. [24.130.62.181]) by smtp.gmail.com with ESMTPSA id s5sm2542549pfh.5.2020.12.06.09.10.27 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 06 Dec 2020 09:10:27 -0800 (PST) To: "Murray S. Kucherawy" , Alessandro Vesely Cc: IETF DMARC WG References: <134860ee-5fbf-2fb3-a5b3-4be68806ab22@mtcc.com> <7224575d-685f-5020-073e-c1880acecc88@mtcc.com> <7e459496-61f8-ddcd-713c-3b6be448090c@gmail.com> <2cecceac-1add-44ec-6e16-e157fee293fe@mtcc.com> <5a577765-4a0d-e1bf-5321-dfeff19d107e@gmail.com> <40d7e78e-7026-c65c-383c-df4e3c537de3@mtcc.com> <18e93db9-bde7-bf49-670c-1e680f2ce3a6@tana.it> <65bbc2a6-701a-1729-7892-ef68c1b6b237@mtcc.com> <5bce5710-6553-36ee-c46e-cbde702141e5@tana.it> From: Dave Crocker Message-ID: <7e4cf4bc-de2b-7f3f-212c-92110f5871b5@gmail.com> Date: Sun, 6 Dec 2020 09:10:25 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] is DMARC informational? X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 06 Dec 2020 17:10:31 -0000 On 12/6/2020 5:57 AM, Murray S. Kucherawy wrote: > DMARC was not published as a product of this working group. which, of course, is explicitly noted in the first line of the DMARC RFC:      "Independent Submission" and by way of a contrasting example, DKIM:      "Internet Engineering Task Force (IETF)" d/ -- Dave Crocker dcrocker@gmail.com 408.329.0791 Volunteer, Silicon Valley Chapter American Red Cross dave.crocker2@redcross.org From nobody Sun Dec 6 09: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 79E0B3A046D for ; Sun, 6 Dec 2020 09:20:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.65 X-Spam-Level: X-Spam-Status: No, score=-1.65 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, 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=mtcc-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VWVI70Hdbnxn for ; Sun, 6 Dec 2020 09:20:37 -0800 (PST) Received: from mail-pf1-x432.google.com (mail-pf1-x432.google.com [IPv6:2607:f8b0:4864:20::432]) (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 E75203A046A for ; Sun, 6 Dec 2020 09:20:36 -0800 (PST) Received: by mail-pf1-x432.google.com with SMTP id 11so1201107pfu.4 for ; Sun, 06 Dec 2020 09:20:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mtcc-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=PZkcE/n0f6zr2tKKrYzHCbga1EzQy168ij+ZYcuysCo=; b=hAjRPpbJJFzf6e1ksyDGHITd1IbQhixRyByRw5hXSDVx8Ap7QZa8DIaHMjkxYM2m0n FR5d3lh6do/CCZw0wBbe8gCq/CDTz2pkIhQNZBtuWJXyGQyRMW2Voj0Sx6Dw9NmGqPe+ bV8Ok3DFBdalCTaCGKBdDtyrNufF58axwQUFyHb/99yELzccx/KVSxG/c1+WI32geiny EprQqIqq7krieNGuAm7NhJAiUSZ0rQLTHDS7Q5h+uN4uvHLIIUXhiERcnmRGWvCQ8tzf dRBwQjJmayBkT2iGi09JPXM3V9bocWhb/dmZhD/LlNPL78U0RhtFc0i2+Xl9BQdq0fZz bR1A== 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=PZkcE/n0f6zr2tKKrYzHCbga1EzQy168ij+ZYcuysCo=; b=RkINMFerl1eqGgn12pnafK0aVNmcEKXISyL5HVExdje/E9Yg5P2r4h8s2Usm+NF1uK 0rhYuzBEMImgLJ8izcAAPnjWou42+9uR1Vk1anUED7+0qm7UE37B0qkdfuNU4sRxau23 tONVvoPbF9++vhWRt6meeU9u8rDfznqXxW0gdxrje2aXZ3xs8GcvCp14UXsLKr7L4r4J zatThirruKuhXXsCfcDt7IeEV4WEKtmBJyOCrqJSGGT8Pmdu6u+DrX2v7EgWtXFUJVhq 9DquUpErAa6eUO9U2RccnB7sHYgYibSy2lUQZ14C5PTXrqgTpwitctlZuuJn/ZL/ThWf JhhQ== X-Gm-Message-State: AOAM531GJTno8+rybpzx+3Vbawl97FhY3Cuk3Eezz/tyOPMUkiMs+I7m XHCFPZfIrEUp3inSEwiXS5KBjy7kAltnUw== X-Google-Smtp-Source: ABdhPJyV3+uLMfWtJCmEGToZ03FAAf6GbOB/ms0TcGmqBaObXnm2UnMHpMFIxwwgqpRUY6LJaIBTdA== X-Received: by 2002:a65:6a4e:: with SMTP id o14mr15371109pgu.65.1607275236006; Sun, 06 Dec 2020 09:20:36 -0800 (PST) Received: from mike-mac.lan (107-182-42-33.volcanocom.com. [107.182.42.33]) by smtp.gmail.com with ESMTPSA id m17sm1636241pgi.11.2020.12.06.09.20.34 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 06 Dec 2020 09:20:35 -0800 (PST) To: dmarc@ietf.org References: <134860ee-5fbf-2fb3-a5b3-4be68806ab22@mtcc.com> <7224575d-685f-5020-073e-c1880acecc88@mtcc.com> <7e459496-61f8-ddcd-713c-3b6be448090c@gmail.com> <2cecceac-1add-44ec-6e16-e157fee293fe@mtcc.com> <5a577765-4a0d-e1bf-5321-dfeff19d107e@gmail.com> <40d7e78e-7026-c65c-383c-df4e3c537de3@mtcc.com> <18e93db9-bde7-bf49-670c-1e680f2ce3a6@tana.it> <65bbc2a6-701a-1729-7892-ef68c1b6b237@mtcc.com> <5bce5710-6553-36ee-c46e-cbde702141e5@tana.it> From: Michael Thomas Message-ID: <1daf772a-e9d0-904c-cbb9-6730d70e4424@mtcc.com> Date: Sun, 6 Dec 2020 09:20:33 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------50A047D3BE537E5D76B6F817" Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] is DMARC informational? X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 06 Dec 2020 17:20:39 -0000 This is a multi-part message in MIME format. --------------50A047D3BE537E5D76B6F817 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 12/6/20 7:13 AM, Dotzero wrote: > > > On Sun, Dec 6, 2020 at 8:58 AM Murray S. Kucherawy > > wrote: > > On Sun, Dec 6, 2020 at 5:09 AM Alessandro Vesely > wrote: > > On chartering the WG in 2013, the decision was made to publish > DMARC as > independent submission, even though it was going to be > discussed and reach > consensus of a IETF WG.  AIUI, that was the original question > of this thread. > > > This isn't correct.  DMARC was not published as a product of this > working group.  It was published through the Independent > Submission stream, which can only produce Informational > documents.  At the time, this was because the group advancing > DMARC wanted to preserve the installed base and not cede change > control to the IETF, so a working group was not an option. > > > Murray, your recollection isn't quite accurate. The group advancing > DMARC was looking to preserve the installed base for a defined period > of time due to a) almost all the implementations were custom code and > b) there was a desire to see more experience in the wild as almost all > of the deployments were by members of the group advancing DMARC. There > was also a political element in that there were folks within IETF that > felt the DMARC folks were only looking for a rubber stamp, nothing > more. This resulted in part of the pushback. > What I still don't understand is what drove the decision to deviate from ADSP. From reading through DMARC, it's basically ADSP nee SSP with provisions for SPF and the new reporting feature. SPF had its own policy at the time, but adding it and the reporting could have been done in the context of an ADSP-bis. Had I been paying attention, I certainly would have supported adding both of those features because they clearly make getting to the end goal better. Mike --------------50A047D3BE537E5D76B6F817 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit


On 12/6/20 7:13 AM, Dotzero wrote:


On Sun, Dec 6, 2020 at 8:58 AM Murray S. Kucherawy <superuser@gmail.com> wrote:
On Sun, Dec 6, 2020 at 5:09 AM Alessandro Vesely <vesely@tana.it> wrote:
On chartering the WG in 2013, the decision was made to publish DMARC as
independent submission, even though it was going to be discussed and reach
consensus of a IETF WG.  AIUI, that was the original question of this thread.

This isn't correct.  DMARC was not published as a product of this working group.  It was published through the Independent Submission stream, which can only produce Informational documents.  At the time, this was because the group advancing DMARC wanted to preserve the installed base and not cede change control to the IETF, so a working group was not an option.

Murray, your recollection isn't quite accurate. The group advancing DMARC was looking to preserve the installed base for a defined period of time due to a) almost all the implementations were custom code and b) there was a desire to see more experience in the wild as almost all of the deployments were by members of the group advancing DMARC. There was also a political element in that there were folks within IETF that felt the DMARC folks were only looking for a rubber stamp, nothing more. This resulted in part of the pushback.


What I still don't understand is what drove the decision to deviate from ADSP. From reading through DMARC, it's basically ADSP nee SSP with provisions for SPF and the new reporting feature. SPF had its own policy at the time, but adding it and the reporting could have been done in the context of an ADSP-bis. Had I been paying attention, I certainly would have supported adding both of those features because they clearly make getting to the end goal better.

Mike

--------------50A047D3BE537E5D76B6F817-- From nobody Sun Dec 6 09:27: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 534483A0762 for ; Sun, 6 Dec 2020 09:27:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.652 X-Spam-Level: X-Spam-Status: No, score=-1.652 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mtcc-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TkQLDzFd7aAt for ; Sun, 6 Dec 2020 09:27:34 -0800 (PST) Received: from mail-pg1-x533.google.com (mail-pg1-x533.google.com [IPv6:2607:f8b0:4864:20::533]) (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 C6DF23A0656 for ; Sun, 6 Dec 2020 09:27:33 -0800 (PST) Received: by mail-pg1-x533.google.com with SMTP id n7so6858588pgg.2 for ; Sun, 06 Dec 2020 09:27:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mtcc-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=69FpotgaSEKM8OujuXlzM6R9pcS8uRG+2OnniJ8DgfY=; b=v4Ls3cvLT+INPsKoOZ44/tWT1UCCFFY/GK0/JQWkugUTkKW+nlhwIDM3uU6U7LnnEA mNrgEhUaHmDP8Q0iERtdkK6y8nfVh2Lx4Rbtr3lw/ICVkcHQhM1/rAFfuctgybDhRqMS Kg5XPa2njHiJj+7v2zQESwKF1Nsb7QaiY6pSwxrCEwIxmme/4LgwamamPKUA5pDtjYgP tG00AnwzJHnPkDIFtH4LHzT8z04eudTMeB0XkYbjqVR/YJ5I68uepK93mDd4eIEOmhkI lduIXSNRCMQNIZ3SCNnDmCnIyx2GmJuWJw0Fx0Whx/HJ/l81peSaGUrCU1AjuNMw6RwD gUTQ== 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=69FpotgaSEKM8OujuXlzM6R9pcS8uRG+2OnniJ8DgfY=; b=uBX55cD3S7CqkNrkNtOkwe3Xo/6lj9xzMKGv930dYTMNBLZ7IyaNGdvwtOCwuYUs70 0K4uXNpsFAG+AtRg1kooVhmjvBll7J/Yu7MOaLJtVg8baAZNMK3fWEP5+w4Qg7TB75H8 dZdGaSXr266hA9WDRiIpcR7ZeyzhZnTepE1oZHdWWkPpN0Albf0EE7zZeSycrH6MK+Uz sQBPv2yTEOxtB/oqhJIKh+xUhrOTKAquc66zAGCjW5wW/BuxQQVIvTGGjvTSR3m+58mv YN2wIGZ+tlVX5rbsEpkQx+G/WsC4qhZKj2rikc3A3B3GVWQt9Q1mgO1HfFXwHifiTSYx g+Dw== X-Gm-Message-State: AOAM530ffSxPSeepnzscWM7WgqBk350YAAz12f6QYhOPbchtV23TEHPN P69/6pX4yYoDqr512VlumbMgae1mOwZGfw== X-Google-Smtp-Source: ABdhPJy3Zjw2fcHncUesnZEJ9GAWD0ZY/l9NV8bkvSdZZL12receiQ/B66c6+oQTqhtfQeTvNGTtJQ== X-Received: by 2002:a63:da0a:: with SMTP id c10mr15299338pgh.145.1607275652778; Sun, 06 Dec 2020 09:27:32 -0800 (PST) Received: from mike-mac.lan (107-182-42-33.volcanocom.com. [107.182.42.33]) by smtp.gmail.com with ESMTPSA id p7sm11448633pfn.56.2020.12.06.09.27.31 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 06 Dec 2020 09:27:32 -0800 (PST) To: dmarc@ietf.org References: <134860ee-5fbf-2fb3-a5b3-4be68806ab22@mtcc.com> <7224575d-685f-5020-073e-c1880acecc88@mtcc.com> <7e459496-61f8-ddcd-713c-3b6be448090c@gmail.com> <2cecceac-1add-44ec-6e16-e157fee293fe@mtcc.com> <5a577765-4a0d-e1bf-5321-dfeff19d107e@gmail.com> <40d7e78e-7026-c65c-383c-df4e3c537de3@mtcc.com> <18e93db9-bde7-bf49-670c-1e680f2ce3a6@tana.it> <65bbc2a6-701a-1729-7892-ef68c1b6b237@mtcc.com> <5bce5710-6553-36ee-c46e-cbde702141e5@tana.it> <8961245c-4d0f-a39a-066b-7d8e96e8468d@gmail.com> From: Michael Thomas Message-ID: <1f2d40d2-b48b-309e-becc-38c7dcdd79d0@mtcc.com> Date: Sun, 6 Dec 2020 09:27:30 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 MIME-Version: 1.0 In-Reply-To: <8961245c-4d0f-a39a-066b-7d8e96e8468d@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] is DMARC informational? X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 06 Dec 2020 17:27:35 -0000 On 12/6/20 7:23 AM, Dave Crocker wrote: > On 12/6/2020 7:13 AM, Dotzero wrote: >> The group advancing DMARC was looking to preserve the installed base >> for a defined period of time > > Work that comes to the IETF often has a significant history before > that, often including a well-developed specification and significant > installed base. > > It is not uncommon to publish that pre-IETF specification as an RFC, > to establish the formal background for the prior work. That's what was > done for DMARC. > > The political -- and, IMO, technical -- issues at the time merely > served to delay seeking standards track for a revised specification, > which is what is now being pursued.  While this amount of delay is > unusual, the sequence is not. > 7 years and counting, 9 years from inception, 12 years from ADSP, and 16 years from SSP certainly speaks volumes as to why people would prefer to avoid sclerotic ietf process. At best, ietf is a discovery mechanism for interesting emerging network protocols, not an arbiter of when they are actually usable. Mike From nobody Sun Dec 6 09:41: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 CF0453A0800 for ; Sun, 6 Dec 2020 09:41:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.651 X-Spam-Level: X-Spam-Status: No, score=-1.651 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mtcc-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7702wvXn8DJ7 for ; Sun, 6 Dec 2020 09:41:16 -0800 (PST) Received: from mail-pf1-x434.google.com (mail-pf1-x434.google.com [IPv6:2607:f8b0:4864:20::434]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BFF8B3A07F7 for ; Sun, 6 Dec 2020 09:41:16 -0800 (PST) Received: by mail-pf1-x434.google.com with SMTP id 131so7435271pfb.9 for ; Sun, 06 Dec 2020 09:41:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mtcc-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=0vODXDts7kdrwiQgChumBlWi/how1G1/rTSyqP87uwc=; b=htpreJfAhsN7WG88SYiHkTF7U1Bd40v9JRBQESc/hU/QWZOSDVkj20ILqAARiQgiG/ Q9dgihoR/UK/Gf7vl6RKoPVYC/1ordy2RLzBcILcEzVFkldlvMAdyP9Gy3dqbAauJ2sI EyzK7wvOkxSj7F0gAZnzQ6Xqi/ck+YM4ZMkcY4cIBWpZktDqv8BsiHE5qpEUGv6QWOxI GxwDrXh8mtCy/+UeCfUzqa0JU6rbr0lUHuxu/UY63VSmlYZNv5CKyf1noh1hPQQw3s2/ FeMg1L2M1sSZ1mIye0kL1Og2qns8dVBlxP2hg8r7nW/QsjSqLkOzEvSQ3F0+TMASKfBS 5peg== 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=0vODXDts7kdrwiQgChumBlWi/how1G1/rTSyqP87uwc=; b=CL34yyq8UGYDKqs8MzHZzFJ7WPM1O6XDa10RcJUk5jBbwQpgH1IwTigM4f/vlz0Yp2 EcBzL7qgfFW37Y4IjC8WMciloBw9HZ10q+CHqxGS7BFl70MKBYjFw7Fs+JMWWTCOBuvM +0qlofaWYeVzugndwl0HnzYCxfb7QB5vKV3oep5ozeKFUXhsfWAv0w6O0zRsGC6Gqb9I kyUHJQlYmr1KK5UYK5VFAUU5ISBYg4TNh8VXglSbTAAOiZpybsVeJk03hHdwbne9UoSj 5TvS34KGlO4/FRRo3AgRze74vyCZWBZWkNYBCaNX0vzDV8fncSdT09gSaGdiUXTqlGQZ b/hQ== X-Gm-Message-State: AOAM530nOgm4fKlaiF0yb3NrIrlUvFi46J/HvSQiZ6BCE9v1OflPHdkn 7q2hUAyqNVlqpW1Pc6DPz/BZYgb5HdwD4Q== X-Google-Smtp-Source: ABdhPJwHuLLiPC+Or4SvJxaAsCJ4xK9LDfQnK8ciec2VBSwa1G1itxuYJNheKUDMpdHCnh/dQ0NPPA== X-Received: by 2002:a62:19ca:0:b029:19d:cd0d:af83 with SMTP id 193-20020a6219ca0000b029019dcd0daf83mr9095733pfz.51.1607276475536; Sun, 06 Dec 2020 09:41:15 -0800 (PST) Received: from mike-mac.lan (107-182-42-33.volcanocom.com. [107.182.42.33]) by smtp.gmail.com with ESMTPSA id v1sm7845502pjs.16.2020.12.06.09.41.14 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 06 Dec 2020 09:41:14 -0800 (PST) To: dmarc@ietf.org References: <20201205210351.DB78E2904420@ary.qy> <28759E60-3A00-4D25-9490-34495B96EE10@bluepopcorn.net> <9c23d850-4164-1320-1c25-40554c1f64b@taugh.com> From: Michael Thomas Message-ID: Date: Sun, 6 Dec 2020 09:41:13 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.5.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] ARC vs reject X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 06 Dec 2020 17:41:18 -0000 On 12/5/20 7:56 PM, Jim Fenton wrote: > > FWIW, I don’t think a lot of the people publishing p=reject understood > the implications of that, either. This is not significantly more arcane. The audience for what I am bringing up are exactly the clueful set who are paranoid about any modifications at all to their mail. I want my bank to be paranoid because, you know, money. Anybody can be clueless and select the wrong policy, but that doesn't mean that the clueful should not have a policy that meets their wishes. Mike From nobody Sun Dec 6 10:31: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 0589D3A0957 for ; Sun, 6 Dec 2020 10:31:36 -0800 (PST) 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 llj2O4iPbW8N for ; Sun, 6 Dec 2020 10:31:34 -0800 (PST) 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 534E53A0940 for ; Sun, 6 Dec 2020 10:31:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1607279490; bh=glrU5KA4+eyui2EGqrCITK7Ejm4XSjDK+MZzU5CCUIU=; l=1934; h=To:References:From:Date:In-Reply-To; b=Byw5v5hE7Ovh94AC8Ht++Lcgb5O2whPBtrEV1p1JQy6NC7oudroOi839R8wcnZ+LA VnoqaGtPp7peEkVHcq8b0LmuxxLYvsPBxkcy7fiMymh993DOue+TE0S78v64Cs205A RSzaXAbNNtdAocS/9WIqh8zX4rwFDv8VmR3WkkJXKwXrzQHN3b9PDG912i/G0 Authentication-Results: tana.it; auth=pass (details omitted) Original-From: Alessandro Vesely 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.000000005FCD2382.000037A3; Sun, 06 Dec 2020 19:31:30 +0100 To: dmarc@ietf.org References: <20201205231059.2BA23290EDCD@ary.qy> <7ae42764-176d-11a8-e084-b10b6f676944@mtcc.com> <8142f18c-ac79-1f94-97d1-2704f0b4ceb6@mtcc.com> <72d32b62-64fb-937a-dac5-6f4c5816f523@mtcc.com> From: Alessandro Vesely Message-ID: <80558d32-2498-f9b3-313f-2211c1731e73@tana.it> Date: Sun, 6 Dec 2020 19:31:30 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] ARC vs reject X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 06 Dec 2020 18:31:36 -0000 On Sun 06/Dec/2020 18:01:04 +0100 Michael Thomas wrote: > On 12/6/20 5:40 AM, Alessandro Vesely wrote: >> On Sun 06/Dec/2020 02:34:45 +0100 Michael Thomas wrote: >>>> >>>> 5) The work you and Alessandro have done with reverse transformation is >>>> more likely to produce a solution for the mailing lists.   The lists will >>>> continue to do From rewrite, but reverse-transform recipients can validate >>>> the true source of the message and restore the From if desired. >>> >>> I'm starting to get a little more serious about my quip that the MLM can >>> insert a sed script in a header to unmangle the message since it knows what >>> transforms it has done, unlike the receiving MTA trying to guess the common >>> transformations. >> >> But then the receiving MTA will have to guess whether the sed script >> considerably alters the intended meaning of the message. For example, does it >> change a bank account number? > > This actually highlights why my observation is correct. If the intermediary > showed how to reverse their changes perfectly to be able to validate the > original signature, it says nothing about whether those changes to be delivered > to the recipient are acceptable to the originating domain. for the case of a > bank sending me sensitive mail, the answer is that it is never ok. for somebody > working on internet standards working on ietf lists, the answer is that it is > fine. hence trying to get two states of the one "reject" is insufficient. For MLM transformations, this choice can be done by tuning DKIM signatures. A bank can choose to sign Sender: field (or lack thereof), or any other fields that a MLM has to change, and possibly use simple canonicalization. In that conditions, transformation reversion won't work. It isn't a distinct DMARC state, formally. Yet, tuning DKIM signatures allows to harden or weaken the given DMARC state. Best Ale -- From nobody Sun Dec 6 10:45: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 A2AE03A09C1 for ; Sun, 6 Dec 2020 10:45:50 -0800 (PST) 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 jmLF4Qn4j1Jp for ; Sun, 6 Dec 2020 10:45:48 -0800 (PST) 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 9E65C3A09BD for ; Sun, 6 Dec 2020 10:45:48 -0800 (PST) Received: by mail-vs1-xe29.google.com with SMTP id z16so6356803vsp.5 for ; Sun, 06 Dec 2020 10:45:48 -0800 (PST) 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=tYCEE10dd77ktelR+OfVD9Mv8KrOTDhhJZkBciSybqI=; b=bRnNGm8Mzgk8dOvZqgqUQzzsXVxJTseJwDTWa1pOeFDGbk2qAZtSCpE0kRBqUav7IV wyYkFdtKNw5k6JF6cgIkmeJoOMeyl1WFWQ3fGslmZxlecF68QFnh+IXW72imAcbehSUD 76yEmM8ZcWxlPWsf4i1HElKRHtQT/HiBk3l1wjirdOdzOgcwiPtGOXr+hYMOp2luP0g+ HVivKh23rCPQrodmjr7TBDsW/IxrbC4CCje7qEo6AiFt9iS/GIOKenwQzU/NouajkMng Lwye9wzX94TJGOcpe97Cwtda3YdzrhsVlNI3TCymOuFrdUE2/Rd4X+cz1Rq17I5mbDbR xJkQ== 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=tYCEE10dd77ktelR+OfVD9Mv8KrOTDhhJZkBciSybqI=; b=lllCa09cs5O+IC6zk+1FJld4asNlK3ev0MPCSIkQ143LlKiYFVK9kMZ78/VJj1O1N+ mEwG7Rzj5FkOZx3rnOydPRKvy78Kyoich/d11CHha3nalshIEMrFpcXGbFa8tLrkGUTF Hw0tb0pt5xyM6tzrPYkaab2NZ3pUjBA9xLsBrdh9hkFnkueukV3aWEjVPFHVdHkSsqeL CS9KN0bHexb+2I7a0UGSlqIRmv7X4mzlVme0l3ztr+VDo1+1l9o26CjSClRzbK9FMxqq /1GIPGXbcV4yXEyOYwH6eeb80va0Z3ylEFJgOJBBmMT8avf3p2mfJRE5MbluT45l+9MV Dbag== X-Gm-Message-State: AOAM532dE7SZA5PraGyj9hf+wjT8In8mKFlYdPdvKu3O07S0uonubgyv UOy2SRSuNl5Pj8046GBKGeVrb4Xb1+3/ZZjX8EiKWzJq9MI= X-Google-Smtp-Source: ABdhPJx6c1q8BUQ6V8ouk4gxz9ZJ6PmJLcz1vh6IsOQXraFHAD82AG0ZHYmiJuGDQngZXjugtYMSCL8kefdn+XKtGWQ= X-Received: by 2002:a67:fad2:: with SMTP id g18mr10692013vsq.45.1607280347493; Sun, 06 Dec 2020 10:45:47 -0800 (PST) MIME-Version: 1.0 References: <20201205210351.DB78E2904420@ary.qy> <28759E60-3A00-4D25-9490-34495B96EE10@bluepopcorn.net> <9c23d850-4164-1320-1c25-40554c1f64b@taugh.com> In-Reply-To: From: Douglas Foster Date: Sun, 6 Dec 2020 13:45:36 -0500 Message-ID: To: dmarc@ietf.org, dmarc-chairs@ietf.ord Content-Type: multipart/alternative; boundary="0000000000002ab8bb05b5d01e55" Archived-At: Subject: Re: [dmarc-ietf] ARC vs reject X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 06 Dec 2020 18:45:51 -0000 --0000000000002ab8bb05b5d01e55 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable The recent discussion has introduced two challenges to ARC: first, that it is too complicated, and second, that it opens up security holes that should be unacceptable. John's response appears to be that the technology will only be used by a small group of lists in cooperation with a small group of recipients, that the complexity will be a non-issue for the participants and the risk, while present, will be mitigated by the limited scope of participation. All of this is problematic. On security issues, we have to assume attacks by state-sponsored actors, not just fortune seekers. So the security challenge needs to be thoroughly vetted. But the participation assumption is even more worrisome. If this is a limited participation protocol, supported by a private but not-yet-created communication network, then it does not solve the chair's requirement for a general solution. I ask the chairs to formally endorse development of an alternative to ARC as an additional approach to the mailing list problem, a solution based on reverse transformation. Alessandro and Murray have submitted drafts. It is time to study their proposals and merge their work. Doug Foster On Sat, Dec 5, 2020 at 11:14 PM John R Levine wrote: > On Sat, 5 Dec 2020, Jim Fenton wrote: > >> Of course not. That's just the tiny gorillas stamping their teensy > feet. > >> Why would anyone expect that the people publishing that flag actually > >> understood what it meant? Many will just turn it on because someone > said > >> it's "more secure." > > > > FWIW, I don=E2=80=99t think a lot of the people publishing p=3Dreject u= nderstood > the > > implications of that, either. This is not significantly more arcane. > > Then I think we agree. There's no difference from p=3Dreject and > p=3Dreject-I-really-mean it. > > > ... If the recipient domain accepts modifications by zero-reputation > > intermediaries (because there are so many of them, after all) > > I wouldn't call that a reasonable implementation of ARC. The set of host= s > that are likely to send you mail with interesting ARC chains is relativel= y > small, and I don't think it changes very fast. Most of the hosts that > send you non-spam mail aren't going to send you mail that needs ARC. > > If you're setting up a new mailing list host or forwarder, getting > yourself into whatever whitelists people use will be somewhat painful but > there's nothing new about that. > > > I=E2=80=99d be interested in other opinions on this. Or whether this is= a > fundamental > > problem with ARC. > > I'd certainly be interested in hearing how people plan to compile and > maintain their lists of ARC-worthy hosts. > > Regards, > John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY > Please consider the environment before reading this e-mail. https://jl.ly > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > --0000000000002ab8bb05b5d01e55 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The recent discussion has introduced two challenges to ARC= :=C2=A0 first, that it is too complicated, and second, that it opens up sec= urity holes that should be unacceptable.=C2=A0 =C2=A0 John's response a= ppears to be that the technology will only be used by a small group of list= s in cooperation with a small group of recipients, that the complexity will= be a non-issue for the participants and the risk, while present, will be m= itigated by the limited scope of participation.=C2=A0 =C2=A0 All of this is= problematic.

On security issues, we have to assume atta= cks by state-sponsored actors, not just fortune seekers.=C2=A0 =C2=A0So the= security challenge needs to be thoroughly vetted.

But the=C2=A0participation assumption is even more worrisome.=C2=A0 =C2=A0= If this is a limited participation protocol, supported by a private but no= t-yet-created communication network, then it does not solve the chair's= requirement for a general solution.=C2=A0 =C2=A0

= I ask the chairs to formally endorse development of an alternative to ARC a= s an additional approach to the mailing list problem, a solution based on r= everse transformation.=C2=A0 =C2=A0Alessandro and Murray have submitted dra= fts.=C2=A0 =C2=A0It is time to study their proposals and merge their work.<= /div>

Doug Foster


On Sat, Dec 5, 202= 0 at 11:14 PM John R Levine <johnl@ta= ugh.com> wrote:
On Sat, 5 Dec 2020, Jim Fenton wrote:
>> Of course not.=C2=A0 That's just the tiny gorillas stamping th= eir teensy feet.
>> Why would anyone expect that the people publishing that flag actua= lly
>> understood what it meant?=C2=A0 Many will just turn it on because = someone said
>> it's "more secure."
>
> FWIW, I don=E2=80=99t think a lot of the people publishing p=3Dreject = understood the
> implications of that, either. This is not significantly more arcane.
Then I think we agree.=C2=A0 There's no difference from p=3Dreject and =
p=3Dreject-I-really-mean it.

> ... If the recipient domain accepts modifications by zero-reputation <= br> > intermediaries (because there are so many of them, after all)

I wouldn't call that a reasonable implementation of ARC.=C2=A0 The set = of hosts
that are likely to send you mail with interesting ARC chains is relatively =
small, and I don't think it changes very fast.=C2=A0 Most of the hosts = that
send you non-spam mail aren't going to send you mail that needs ARC.
If you're setting up a new mailing list host or forwarder, getting
yourself into whatever whitelists people use will be somewhat painful but <= br> there's nothing new about that.

> I=E2=80=99d be interested in other opinions on this. Or whether this i= s a fundamental
> problem with ARC.

I'd certainly be interested in hearing how people plan to compile and <= br> maintain their lists of ARC-worthy hosts.

Regards,
John Levine, johnl@tau= gh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly__________= _____________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
--0000000000002ab8bb05b5d01e55-- From nobody Sun Dec 6 10:47: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 047D93A09C9 for ; Sun, 6 Dec 2020 10:47:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.652 X-Spam-Level: X-Spam-Status: No, score=-1.652 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mtcc-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3OFNWPqVYcbw for ; Sun, 6 Dec 2020 10:47:28 -0800 (PST) Received: from mail-pl1-x629.google.com (mail-pl1-x629.google.com [IPv6:2607:f8b0:4864:20::629]) (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 C80CE3A09C6 for ; Sun, 6 Dec 2020 10:47:28 -0800 (PST) Received: by mail-pl1-x629.google.com with SMTP id 4so5974222plk.5 for ; Sun, 06 Dec 2020 10:47:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mtcc-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=tFoPQmL7QlS7GTnTMSK2BeurY0FPMMEPoDdpk9+eqwM=; b=cFaVaFVEKQtnehH5r9QP2H0ZZhDOKVkXxQmYVui5NAIEu2w00W+7YwO7d+D4PNUCIm QR37mB2YB0YsdBWNDze0luj8uNXRl021bhD8Pi6iSqr7YkvM/cqTwPRZuL9pQhGfbk3R M8wjpWPL8c58WYXa9OeVLg9DU6FWtzO0SQi/EFhgQW2J8qyapU3KlErw3o437zD0CMmj XuRHIwYaC67yXaP2VGylwyv5hLtIXhvdclf5RhPH8LriZeSj+ry9EOnXy7+IxvpQVzxZ d6j7Beecdvf2onUKOQsd5etgDwQD6DWwVGDpjvqMz8/o3n7uHHpfqYFg+k4d5EoldV7+ WQ4g== 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=tFoPQmL7QlS7GTnTMSK2BeurY0FPMMEPoDdpk9+eqwM=; b=ikWJgIjtd5lR4LZsIxh0lBDdMlGeM3IqmD7TCUTTP3JavdC4qjNyNqWbmwPeqY1bG3 ShZNWm/L63OHu0DDdEUSH1uGBMWS2jB5WWOJmvGi+J2Gfri9XRGN1k3A6XAr60QOmlh9 vZiFiYf45CMQVqjxfLcdqqKpPFkR4/mt/e4cLpKvqnPiIZCJPAfekrSy3CtloH4soKW0 RPjcco33QkyJjxHmmL8xLSBAIUiasRBRIe68OSq5D4YuAqteTbwE3DD08jLsx8SSg5xc 3tjFPXYJcwqH+i/kwb009sVS605Grz4k74i+iAsGlkZl+2YwUuvrGR7r7/c1GWP8JVi+ vc5Q== X-Gm-Message-State: AOAM531Cd0xHk14T7Ns7Ys5EB9ulbPalxQK/8GdDXfqZU1andxHBgw7w tnYnXhDwAW1+Eivnu5zbpLHpt4wTXMrcFA== X-Google-Smtp-Source: ABdhPJya9Nh/UVbMZBLR2aQGV0yqnpFRAIbppQxpWuq3Cdy6SrBNTelwZOuRRgGh7MlHvnxvyqlqkQ== X-Received: by 2002:a17:90a:c8d:: with SMTP id v13mr13362240pja.75.1607280446464; Sun, 06 Dec 2020 10:47:26 -0800 (PST) Received: from mike-mac.lan (107-182-42-33.volcanocom.com. [107.182.42.33]) by smtp.gmail.com with ESMTPSA id x6sm9501963pfq.57.2020.12.06.10.47.25 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 06 Dec 2020 10:47:25 -0800 (PST) To: dmarc@ietf.org References: <20201205231059.2BA23290EDCD@ary.qy> <7ae42764-176d-11a8-e084-b10b6f676944@mtcc.com> <8142f18c-ac79-1f94-97d1-2704f0b4ceb6@mtcc.com> <72d32b62-64fb-937a-dac5-6f4c5816f523@mtcc.com> <80558d32-2498-f9b3-313f-2211c1731e73@tana.it> From: Michael Thomas Message-ID: Date: Sun, 6 Dec 2020 10:47:24 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 MIME-Version: 1.0 In-Reply-To: <80558d32-2498-f9b3-313f-2211c1731e73@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] ARC vs reject X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 06 Dec 2020 18:47:30 -0000 On 12/6/20 10:31 AM, Alessandro Vesely wrote: > On Sun 06/Dec/2020 18:01:04 +0100 Michael Thomas wrote: >> >> This actually highlights why my observation is correct. If the >> intermediary showed how to reverse their changes perfectly to be able >> to validate the original signature, it says nothing about whether >> those changes to be delivered to the recipient are acceptable to the >> originating domain. for the case of a bank sending me sensitive mail, >> the answer is that it is never ok. for somebody working on internet >> standards working on ietf lists, the answer is that it is fine. hence >> trying to get two states of the one "reject" is insufficient. > > > For MLM transformations, this choice can be done by tuning DKIM > signatures.  A bank can choose to sign Sender: field (or lack > thereof), or any other fields that a MLM has to change, and possibly > use simple canonicalization.  In that conditions, transformation > reversion won't work.  It isn't a distinct DMARC state, formally.  > Yet, tuning DKIM signatures allows to harden or weaken the given DMARC > state. > It seems a lot simpler for the originating domain to just be explicit about how they feel about transformations by intermediaries. It's not like another short ascii string is going to break the bank. Mike From nobody Sun Dec 6 11:02: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 C90A73A09F9 for ; Sun, 6 Dec 2020 11:02:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.651 X-Spam-Level: X-Spam-Status: No, score=-1.651 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, 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=mtcc-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TNoESutWEke2 for ; Sun, 6 Dec 2020 11:02:33 -0800 (PST) Received: from mail-pf1-x436.google.com (mail-pf1-x436.google.com [IPv6:2607:f8b0:4864:20::436]) (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 259223A09F5 for ; Sun, 6 Dec 2020 11:02:33 -0800 (PST) Received: by mail-pf1-x436.google.com with SMTP id d2so3645277pfq.5 for ; Sun, 06 Dec 2020 11:02:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mtcc-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=FbKBUHQfAOM4igNpt2tzrqk0eywfu9vwe7LJGZaTIb4=; b=aq9po3LZjcTEdsHZA4McHXdIhcnL93rPrqC40znP/n/c2MEolVTD7YWbYkYZTN2WAn ureOjz1MvgB0laKMHaxNWgImsQdVMQEbhY4d31NFPGN9LpZ5iJo+C4P0cj+LbDLd7qrv Tu2lfszktrC+tV9S+CmTz9cF8YuTOCE8rtj9q88r72n1+S5EC/IXY3jlCNhL3D0JiImt XWPKa0gmg5ore++BSPIrUZ3GWAV0XPXTfUttTqVYSLW/BZRtUsSk8DxDuXSrolhndBu4 Bk/MEiapRsObHmaetAFrp5nVX8H2RMZBT7hlhUoI6/AjSKYR/mEyWpS/mQwLLw83eprq 0A3A== 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=FbKBUHQfAOM4igNpt2tzrqk0eywfu9vwe7LJGZaTIb4=; b=mQhGrsR4f1NO25EvAxFmssJlzl/XiP3LKOY+8Ybo6Ts5ZoDrooCDFzBjWIfol0ikzm nFQAuhlCqAMalO8XPfoLUngxiLHUFZxSAO1BUoT75R/W3WtXwQbYnzPsp0CKJaK99m2F 3IDhAfiZeP2LbyEBJvNJdt2lT7xjuyWPITwrE5NBrXICeaJKVJwpNlbKk4OcIY97CHj6 pY5pX6V52x9UKXYjc/by9EFzBuLDMI3y1nOkf79GZCt7rOaNM98gc878PBN90HBhB8Z5 ghHoNBL7cGcK4GDRF+wMXYMP3IDLUl4QRVqrgNo93luxgIFA9SmCWIjUERXiXPaCWxoE gT7Q== X-Gm-Message-State: AOAM533ZgdlDQebbNLDJGwxA7yWpEIQIzxvwWpO8/K9R6O/veGSTWb1P fnsHNWJtek7gVEoGCPyBG2v1VCdn68CTjA== X-Google-Smtp-Source: ABdhPJzizM5d0NyyD4MFrrGGVBTCSi2BSwGrZyLTVcpZd3uTY5keCQ0LNj/7ztnCSgmtkLR43SN6Qw== X-Received: by 2002:a63:5856:: with SMTP id i22mr15651342pgm.349.1607281352127; Sun, 06 Dec 2020 11:02:32 -0800 (PST) Received: from mike-mac.lan (107-182-42-33.volcanocom.com. [107.182.42.33]) by smtp.gmail.com with ESMTPSA id u15sm3651831pju.7.2020.12.06.11.02.31 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 06 Dec 2020 11:02:31 -0800 (PST) To: dmarc@ietf.org References: <20201205210351.DB78E2904420@ary.qy> <28759E60-3A00-4D25-9490-34495B96EE10@bluepopcorn.net> <9c23d850-4164-1320-1c25-40554c1f64b@taugh.com> From: Michael Thomas Message-ID: Date: Sun, 6 Dec 2020 11:02:30 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.5.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] ARC vs reject X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 06 Dec 2020 19:02:35 -0000 On 12/6/20 10:45 AM, Douglas Foster wrote: > The recent discussion has introduced two challenges to ARC:  first, > that it is too complicated, and second, that it opens up security > holes that should be unacceptable.    John's response appears to be > that the technology will only be used by a small group of lists in > cooperation with a small group of recipients, that the complexity will > be a non-issue for the participants and the risk, while present, will > be mitigated by the limited scope of participation.    All of this is > problematic. > > On security issues, we have to assume attacks by state-sponsored > actors, not just fortune seekers.   So the security challenge needs to > be thoroughly vetted. > > But the participation assumption is even more worrisome. If this is a > limited participation protocol, supported by a private but > not-yet-created communication network, then it does not solve the > chair's requirement for a general solution. Indeed, I wonder if ietf.org would meet that criteria for "small group of lists". > > I ask the chairs to formally endorse development of an alternative to > ARC as an additional approach to the mailing list problem, a solution > based on reverse transformation.  Alessandro and Murray have submitted > drafts.   It is time to study their proposals and merge their work. > Based on the work I did at Cisco 15 years ago which essentially was a heuristic based form of those two drafts, I found that it worked for about 90 some percent. I unfortunately do not know what the nature of the remaining messages that could not be recovered (either I never did the analysis or don't remember). Things may have changed some since then, but that was what we got for the entire mail stream of a large company. Is that "good enough"? Or better yet, what is the definition of "good enough"? That's probably the most important question out of all of this: what is the success criteria? Our success criteria was that we wanted to mark up messages that were possible spear phishing, so the success criteria was some given false positive rate, with whitelists to mop up some of the corner cases. But that was a very enterprise-y criteria. The larger success criteria needs to encompass a far larger set of use cases. Mike From nobody Sun Dec 6 12:21: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 BAEF83A0B4E for ; Sun, 6 Dec 2020 12:21:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.651 X-Spam-Level: X-Spam-Status: No, score=-1.651 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mtcc-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nbimh9DQzHtv for ; Sun, 6 Dec 2020 12:21:44 -0800 (PST) Received: from mail-pf1-x42f.google.com (mail-pf1-x42f.google.com [IPv6:2607:f8b0:4864:20::42f]) (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 8800E3A0B49 for ; Sun, 6 Dec 2020 12:21:44 -0800 (PST) Received: by mail-pf1-x42f.google.com with SMTP id 131so7654544pfb.9 for ; Sun, 06 Dec 2020 12:21:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mtcc-com.20150623.gappssmtp.com; s=20150623; h=to:from:subject:message-id:date:user-agent:mime-version :content-transfer-encoding:content-language; bh=WZoOeWLAXuAXB34V43uNc6H144nOSVAe2WrAM99X924=; b=SN/oh+jstN5mlHXKsZdDFWVYXmwCmH/V632NtzP9/xmBTpWrb03e7YhJ14hWDunQaB Q4N49BPgGsGD1NzpVn7QpU5BYXWmXttqZFQZqgfu53Ag0WB2awn7k4lK/HWx3041iNN3 aDBOuSQTidgPqC4AcURgvs2cStiPijxTaPtN1pfkzMbW5Lqs1F9rYbLZN6XE4TpN5Fki KyquwMiGkf8FbG8/hcmblJaQtnfDPsn+1dZIzdLOhjK6GDyedHRG/7fMCPFlnpe7N/gp H0lgzc2qJ/bwov8+9ceEOPhqbKZzJvRodM69ofI13p6BDYdpWobjJ/9xwpj1x2f505QV 3ujQ== 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-transfer-encoding:content-language; bh=WZoOeWLAXuAXB34V43uNc6H144nOSVAe2WrAM99X924=; b=jwNcVj/YRv0XAl3fdZqiYo5iPWjRKkmxRbDAv1WxVraffS5U04+cj2eiZy1+jjSk36 eQHM7gsOgPd2O7s3RgaNxJH+UwCJ/B2HQa7V6MIVQqbTyMl8UFp4sZHCuq0QICskjzo4 rEi8LDhtRsKW4OAajNTPH/m9R89jeSq6kVLtjIeycO9nUtQSkzNdsUOsFd+XDzpQ1RDq 32qzNuG7k9QgpNeWtQE+og1EoPAb111FNl5EiJZDN3jMtApDB40hYW7JHSdsLMcVFLQl vtHxXSXBpvszJ3TG8RkxowzRXPXJ/hZJ3uTxMnEFtqQ7+22Yj0Z0oP+wECE2i+zb8jMk /KBw== X-Gm-Message-State: AOAM531C0VnXosuNgDq4qIZf+GU1VtmOoqkpu9E1TztWfPGpRmN+45z5 zVqyS2ClZ/YhOkSfQXYdqMuURiwegHvUjA== X-Google-Smtp-Source: ABdhPJzNNBjXX4bIIKIB76VxHJvyZLCrQ6j7dpt9qzcMpePlb0VWPgNV671L18fexBFPTgUOsrxCow== X-Received: by 2002:a05:6a00:80b:b029:198:124a:d58a with SMTP id m11-20020a056a00080bb0290198124ad58amr12750814pfk.56.1607286102350; Sun, 06 Dec 2020 12:21:42 -0800 (PST) Received: from mike-mac.lan (107-182-42-33.volcanocom.com. [107.182.42.33]) by smtp.gmail.com with ESMTPSA id u1sm8155650pjn.40.2020.12.06.12.21.41 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 06 Dec 2020 12:21:41 -0800 (PST) To: "dmarc@ietf.org" From: Michael Thomas Message-ID: <24757248-20d6-5d7f-b226-2420a1e75f91@mtcc.com> Date: Sun, 6 Dec 2020 12:21:40 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: [dmarc-ietf] draft dkim-transforms X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 06 Dec 2020 20:21:46 -0000 I scanned through Murray's draft and wonder if it's been implemented? Or whether we could in some way simulate what percentage of traffic it would work for? It mostly mirrors a lot of the things I did way back when, but it does go farther with some of the MIME stuff. The advantage I had with my heuristics and z= stuff is that it doesn't require cooperation with the mailing list software, so I could actually run numbers to see how well it was working. As I said earlier, I think the basic question is what constitutes success. Mike From nobody Sun Dec 6 13:12: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 E05513A0C00 for ; Sun, 6 Dec 2020 13:12:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.651 X-Spam-Level: X-Spam-Status: No, score=-1.651 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mtcc-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zcDFxW9l1lUl for ; Sun, 6 Dec 2020 13:12:32 -0800 (PST) Received: from mail-pg1-x533.google.com (mail-pg1-x533.google.com [IPv6:2607:f8b0:4864:20::533]) (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 817B53A0BFD for ; Sun, 6 Dec 2020 13:12:32 -0800 (PST) Received: by mail-pg1-x533.google.com with SMTP id e23so7130181pgk.12 for ; Sun, 06 Dec 2020 13:12:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mtcc-com.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=eVAu55X88WuLcPouYIeA2z99oHKpntXp6hYI7/ZfcVY=; b=PQq3XiXpgXg7+cbvjl1X2fJeI615a3t25+hCgj3Tt2cmNE+BV+jco2AyLnLEa03cRF FelQxstmJG4M68qvG17857hPy4gLtjL2EC5PjGoRFZqPKP+MAHYHzgp0G6ypU3S2TJoY TxKsmqmxXSAJJfyXGU1VfypWIOsrX6oROhHlE6+c1fkvCq06jWkk2ncUyXKvUvT9buNz kFn8elABzBaHoYcZYyQviZdI8jTZPMbfGIWzQBFWtz2qoLuTQug91Sl2YvNVIaDdwgKI jJpnYbWyCMYIVe40VSJiLHR5wBQev2ECXcYnnZyfY2y8bu4jwQ1qxyROdpkAEqlKC4vW 0zOA== 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=eVAu55X88WuLcPouYIeA2z99oHKpntXp6hYI7/ZfcVY=; b=HsilmPC169Ow6k7MIlRQK5ArCd+QNVH/J2TaKYflJVunSbmEFq0Jzp5gpsy2uqjatW Boj6RRusZ8/EGoVoIsiENaFoZJBqPsLmFQQv3hUhmr8pPHrTYFMczUk3MUdecLBDRge5 4Hqm72koBam3nH3KS4NSeMSt6rit5g5vp/N6/3JkKx7uY6euht80r3IvW/N3E+LHsSMU h4OrDwxYsQACwJsBPHuO3S2G1KPhs3YqOk+5t5XZ4UnxJqBRXBazfWaJ8iLXzANX98o4 vLZD52TLzrVAVZYPqYyJsQtdYpj9C11f6dxdcAreKiuKHm9QU8MJnZhY07aEmxocz/A2 0hAA== X-Gm-Message-State: AOAM5318TYvcUVTIv2Mvh3CCG/MveW9i7y9LcpcyRhXlNb3cNczzbMrz DLd7BwygV0s2sDrS6HTQ9yPLR5Ekxvv5LA== X-Google-Smtp-Source: ABdhPJz7KyBlNk5o8VIL2hwh33jT30kpjN36iiG/1XNGsVmnNjWGOo9HXASFRLgzzTjjolSfO8kVuw== X-Received: by 2002:a17:902:bd8d:b029:da:fcd1:664 with SMTP id q13-20020a170902bd8db02900dafcd10664mr232848pls.30.1607289151407; Sun, 06 Dec 2020 13:12:31 -0800 (PST) Received: from mike-mac.lan (107-182-42-33.volcanocom.com. [107.182.42.33]) by smtp.gmail.com with ESMTPSA id x6sm9434863pgr.20.2020.12.06.13.12.29 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 06 Dec 2020 13:12:30 -0800 (PST) To: Jim Fenton , John Levine Cc: dmarc@ietf.org References: <20201205210351.DB78E2904420@ary.qy> <28759E60-3A00-4D25-9490-34495B96EE10@bluepopcorn.net> From: Michael Thomas Message-ID: Date: Sun, 6 Dec 2020 13:12:29 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 MIME-Version: 1.0 In-Reply-To: <28759E60-3A00-4D25-9490-34495B96EE10@bluepopcorn.net> Content-Type: multipart/alternative; boundary="------------0F4A361C9B62F081A0584245" Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] ARC vs reject X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 06 Dec 2020 21:12:34 -0000 This is a multi-part message in MIME format. --------------0F4A361C9B62F081A0584245 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 12/5/20 6:04 PM, Jim Fenton wrote: > > I’d like to step back from the specific use case of “a bank”. > > If a domain publishes p=reject, they’re requesting particular handling > of a message they originate. ARC modifies that, which is good for > mailing lists and similar intermediaries, but depends on a list of > trusted intermediaries that is not under the control of the > originating domain. That increases the attack surface for DMARC > considerably. > > The question I have is: Should DMARC have a policy (or policy > modifier) that says, “Do not accept modifications to this message?” In > other words, that the originator values the integrity of their > messages over deliverability. I'm in the middle of reading rfc  7960 and lo and behold I found this. So I'm not the only one who has thought about this. " To further complicate the usage of mitigations, mitigation may not be desired if the email in question is of a certain category of high value or high risk (security-related) transactional messages (dealing with financial transactions or medical records, for example). In these cases, mitigating the impact of DMARC due to indirect email flows may not be desirable (counterproductive or allowing for abuse)" And the example they use is exactly the example I used. Mike --------------0F4A361C9B62F081A0584245 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit


On 12/5/20 6:04 PM, Jim Fenton wrote:

I’d like to step back from the specific use case of “a bank”.

If a domain publishes p=reject, they’re requesting particular handling of a message they originate. ARC modifies that, which is good for mailing lists and similar intermediaries, but depends on a list of trusted intermediaries that is not under the control of the originating domain. That increases the attack surface for DMARC considerably.

The question I have is: Should DMARC have a policy (or policy modifier) that says, “Do not accept modifications to this message?” In other words, that the originator values the integrity of their messages over deliverability.
I'm in the middle of reading rfc  7960 and lo and behold I found this. So I'm not the only one who has thought about this.

"

To further complicate the usage of mitigations, mitigation may not be
   desired if the email in question is of a certain category of high
   value or high risk (security-related) transactional messages (dealing
   with financial transactions or medical records, for example).  In
   these cases, mitigating the impact of DMARC due to indirect email
   flows may not be desirable (counterproductive or allowing for abuse)"


And the example they use is exactly the example I used.

Mike

--------------0F4A361C9B62F081A0584245-- From nobody Sun Dec 6 20:49: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 C37223A00D3 for ; Sun, 6 Dec 2020 20:48:58 -0800 (PST) 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 bdE8bnaK2oU2 for ; Sun, 6 Dec 2020 20:48:57 -0800 (PST) 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 53BA63A0FDA for ; Sun, 6 Dec 2020 20:48:57 -0800 (PST) Received: by mail-vs1-xe29.google.com with SMTP id b23so6851203vsp.9 for ; Sun, 06 Dec 2020 20:48:57 -0800 (PST) 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=Mfn+qLf4DSMaX1J+m26gbU8ReAu98qGCJbck+DAm7gw=; b=scxAWf6qcRxvdhtN+Jktg1BtOIvLPuw4lGvx3zQkVcmA+xpQZu02jk2pNIQabtHCAy xOjq4DQhzcnvEDC6pkn/WEtpvyrQML8YGEf7PgEz73C8C9WEumfe7aWDZY8IHKYiNV3b VwczZg0/MpzF2NkzY2z3OF6KQXHCi3Pmon9NAX4p9NNJMuaRwIiBnTC/uC7zRAku+57P zIg7q3VCLG+GRhw/8LYdzX1R/bOD+25YvoIdzq/VOAVg0g+6UvhENNLnYK1O36SbqCcz Bmno6bN3CyX459Ghk84TjtjozW75rdopUQ2AmvOUDWBhG3KovdEMq+sup7Ape3536Iev 24KA== 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=Mfn+qLf4DSMaX1J+m26gbU8ReAu98qGCJbck+DAm7gw=; b=DS88niuLS7qQRwocixBfdvYmiCtMIYtCpyYJl5WlTCQzrN1Vkg39JxdIiBxc2/lZ/y xAem0Nmep3T/tKZRsd5QEmQBFN7i9FV+CaxsWTFgdumdq9BfFHOr+vrFQ3sTkSTMr5FQ nQF7WRHYNNyoWVeEU0HtuPzUgpKOODzsRzwphyK1t70zCAZOw9N3FJFc2aURGAbL1G/I DxSBv/iIWGy/S/y3VVJf13newGhSi4zWLM1iLKBSYysFinA44q2AQP1uujFn4ep4TKEc yy9jDCwPnSLXsAxmpwubguEHpp4qYL/IRKjzNNaKpwgWGEl7ne+ZgRyTdOOYqlmdw/aU mqEw== X-Gm-Message-State: AOAM532uPKH/dX/ETf3tLqoxk0EhO581BaH8t4Pahwn6dVGv5ajcX9Q4 +hdVGdB0Y6Uas3TMkAnufp0J6n6PR9R4xa8K6B247Cyw X-Google-Smtp-Source: ABdhPJy/Ce35YQSSh1eZd/+cgsxeFRMxssJD+BuH/nB/6iWA7bsTMFYonLJ5V8LDBC8nuIjnNUeA/LH62v9nmS30g8E= X-Received: by 2002:a67:1d07:: with SMTP id d7mr11006930vsd.33.1607316536211; Sun, 06 Dec 2020 20:48:56 -0800 (PST) MIME-Version: 1.0 References: <134860ee-5fbf-2fb3-a5b3-4be68806ab22@mtcc.com> <7224575d-685f-5020-073e-c1880acecc88@mtcc.com> <7e459496-61f8-ddcd-713c-3b6be448090c@gmail.com> <2cecceac-1add-44ec-6e16-e157fee293fe@mtcc.com> <5a577765-4a0d-e1bf-5321-dfeff19d107e@gmail.com> <40d7e78e-7026-c65c-383c-df4e3c537de3@mtcc.com> <18e93db9-bde7-bf49-670c-1e680f2ce3a6@tana.it> <65bbc2a6-701a-1729-7892-ef68c1b6b237@mtcc.com> <5bce5710-6553-36ee-c46e-cbde702141e5@tana.it> <1daf772a-e9d0-904c-cbb9-6730d70e4424@mtcc.com> In-Reply-To: <1daf772a-e9d0-904c-cbb9-6730d70e4424@mtcc.com> From: "Murray S. Kucherawy" Date: Sun, 6 Dec 2020 20:48:43 -0800 Message-ID: To: Michael Thomas Cc: IETF DMARC WG Content-Type: multipart/alternative; boundary="0000000000002ebea005b5d88b32" Archived-At: Subject: Re: [dmarc-ietf] is DMARC informational? X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 07 Dec 2020 04:48:59 -0000 --0000000000002ebea005b5d88b32 Content-Type: text/plain; charset="UTF-8" On Sun, Dec 6, 2020 at 9:20 AM Michael Thomas wrote: > What I still don't understand is what drove the decision to deviate from > ADSP. From reading through DMARC, it's basically ADSP nee SSP with > provisions for SPF and the new reporting feature. SPF had its own policy at > the time, but adding it and the reporting could have been done in the > context of an ADSP-bis. Had I been paying attention, I certainly would have > supported adding both of those features because they clearly make getting > to the end goal better. > As I recall, people took a run at trying ADSP and it was largely unsuccessful. I recall at least Yahoo, PayPal, and Google trying it but finding that it interfered with their employees' participation in lists, so they each invented new domains for their employees to use as separate from their operational public services. This basically led to its demise. This might also be because there weren't significant actors pushing for it, or because it was basically an all-or-nothing prospect, or because its scope in terms of domain name coverage was too limited. DMARC was in some ways a second attempt at ADSP that tried to address those apparent defects. In addition to reporting, the Organizational Domain, "pct", and "sp" were considered major features at the time. -MSK --0000000000002ebea005b5d88b32 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sun, Dec 6, 2020 at 9:20 AM Michael Th= omas <mike@mtcc.com> wrote:
<= /div>
=20 =20 =20
What I still don't understand is what drove the decision to deviate from ADSP. From reading through DMARC, it's basically ADS= P nee SSP with provisions for SPF and the new reporting feature. SPF had its own policy at the time, but adding it and the reporting could have been done in the context of an ADSP-bis. Had I been paying attention, I certainly would have supported adding both of those features because they clearly make getting to the end goal better.

As I recall, people= took a run at trying ADSP and it was largely unsuccessful.=C2=A0 I recall = at least Yahoo, PayPal, and Google trying it but finding that it interfered= with their employees' participation in lists, so they each invented ne= w domains for their employees to use as separate from their operational pub= lic services.=C2=A0 This basically led to its demise.

<= div>This might also be because there weren't significant actors pushing= for it, or because it was basically an all-or-nothing prospect, or because= its scope in terms of domain name coverage was too limited.=C2=A0 DMARC wa= s in some ways a second attempt at ADSP that tried to address those apparen= t defects.

In addition to reporting, the Organ= izational Domain, "pct", and "sp" were considered major= features at the time.

-MSK
--0000000000002ebea005b5d88b32-- From nobody Sun Dec 6 20:50: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 4C58D3A0FE8 for ; Sun, 6 Dec 2020 20:50:48 -0800 (PST) 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 SAtkICbMIF2p for ; Sun, 6 Dec 2020 20:50:47 -0800 (PST) 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 108223A00D3 for ; Sun, 6 Dec 2020 20:50:47 -0800 (PST) Received: by mail-ua1-x932.google.com with SMTP id g3so4081153uae.7 for ; Sun, 06 Dec 2020 20:50:47 -0800 (PST) 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=jWOAbO70fVDSK5fU0oT09p9+17jkG+thjJ16JuSeaCs=; b=SySzq5qkyA1pOdYs8eNjmvQWBDEB68oSqdhrIPO59yERHX1QJhkEPCdw8p/R64uhWq rZgdEXErN6qA45lZMsYamSB5KIruxbbojOIAB1aHcCR/hrLcPPXFg3fYdq9C807RXGFf lj3MiED2/NKaW0xFg2If3mGUcxrw+rGISvIjSkZjJW7EHzpbsbNT6Lrb5frq+HoMGDeU 5zCnXNCcshR1QZwZwo7Px2BEgOK20OwH+ZL/BbuV8nh7YtoL5aO8/05l68EUco2sp4dj /XvdL0JKVDJsZlykQTUl01/YeZy2nmLp1yJ0YUMJ3XVO0cAnY0kOim41b+NWH6mo4k5D 4jHQ== 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=jWOAbO70fVDSK5fU0oT09p9+17jkG+thjJ16JuSeaCs=; b=Gmnr75iRzu/GrdqqvurT7JsP59Aa1Rw7LagMYUhUapfzolyG3sCcL2z/9M7jcrgw+w ze73ho64O9TC/QtIiZ3uyckAYQVM/3ziem3YGbSOU1gS32Ya4x8xOk3V6X9a4vpiauuK 7AApv2IwcTjIixxGPsBou62TCnjKgb83wWIX5RXu4efGrRHivXMi4yLhEGYxbFFUd59/ NX0j0kp68UM6Ll65dWVyf1VDKZT4+ZO4UQzyLm4U8GJB5/51+TI8XHyzRz/N/t424h6e 7ua4kfdifL3WGnZoPNMsDPgWiVYQYW4Ig4sRR+21DYFb/rE6rTauU2ft8h/4r9Oz5f3P hRgA== X-Gm-Message-State: AOAM531mqZ1nvNFrwbPJRZIpMc6zWsfiSVQjfCgAt4wD3pZrRbEjQPjS wrlOh+X9Ul6nb0U6+NC2hxqSlN8N8kyHU0OyINue1N4R X-Google-Smtp-Source: ABdhPJyRMY+ieclwO2LL1gNIbtRsdTa1sH5hG+/dtUcDde1Te9uauhHwUOURwCvez4WAMAyQdQYDgY8TTfErqVaweXs= X-Received: by 2002:ab0:4881:: with SMTP id x1mr10908901uac.101.1607316646003; Sun, 06 Dec 2020 20:50:46 -0800 (PST) MIME-Version: 1.0 References: <24757248-20d6-5d7f-b226-2420a1e75f91@mtcc.com> In-Reply-To: <24757248-20d6-5d7f-b226-2420a1e75f91@mtcc.com> From: "Murray S. Kucherawy" Date: Sun, 6 Dec 2020 20:50:32 -0800 Message-ID: To: Michael Thomas Cc: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="000000000000ba086605b5d891c9" Archived-At: Subject: Re: [dmarc-ietf] draft dkim-transforms X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 07 Dec 2020 04:50:48 -0000 --000000000000ba086605b5d891c9 Content-Type: text/plain; charset="UTF-8" On Sun, Dec 6, 2020 at 12:21 PM Michael Thomas wrote: > I scanned through Murray's draft and wonder if it's been implemented? Or > whether we could in some way simulate what percentage of traffic it > would work for? It mostly mirrors a lot of the things I did way back > when, but it does go farther with some of the MIME stuff. The advantage > I had with my heuristics and z= stuff is that it doesn't require > cooperation with the mailing list software, so I could actually run > numbers to see how well it was working. > > As I said earlier, I think the basic question is what constitutes success. > Most of the time the discussion resulting from the draft has resulted in lukewarm interest at best, so I never implemented it (or I did, but never released it, and that was a while ago). -MSK --000000000000ba086605b5d891c9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sun, Dec 6, 2020 at 12:21 PM Michael T= homas <mike@mtcc.com> wrote:
=
I scanned through Murray's draft and wonder if it's been im= plemented? Or
whether we could in some way simulate what percentage of traffic it
would work for? It mostly mirrors a lot of the things I did way back
when, but it does go farther with some of the MIME stuff. The advantage I had with my heuristics and z=3D stuff is that it doesn't require
cooperation with the mailing list software, so I could actually run
numbers to see how well it was working.

As I said earlier, I think the basic question is what constitutes success.<= br>

Most of the time the discussion resulti= ng from the draft has resulted in lukewarm interest at best, so I never imp= lemented it (or I did, but never released it, and that was a while ago).

-MSK
--000000000000ba086605b5d891c9-- From nobody Sun Dec 6 21:05: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 A30FB3A0FF7 for ; Sun, 6 Dec 2020 21:05:44 -0800 (PST) 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 NouQfGjcau7g for ; Sun, 6 Dec 2020 21:05:43 -0800 (PST) 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 EF3373A0FF9 for ; Sun, 6 Dec 2020 21:05:42 -0800 (PST) Received: by mail-ua1-x92a.google.com with SMTP id 4so2747337uap.8 for ; Sun, 06 Dec 2020 21:05:42 -0800 (PST) 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=fhnFO/AgiUnpVe/kOO8qr/fk5V+Vs0bVv0iWqS3BYVI=; b=jadrq3AB37JCbJXswUloJ6MVD3Ot3oXn16Ha9Nii0uW3CnIE3bsVfCj0O58BKBk+kd Df0aNehAnc1pawYS6QX4QoOJ5MVQYgzG4iEWc7Kehz6lzmjhSkUoz6mL29Mdf/LqWWgG BAl/lzJBBV1Gx/xgFHXPmcSo/VKZFda8J4zqGvQUu+rAmip37zQS4mzskrDnvLfag2Jw gJlJCJ3XSS5/mXDql3kBUtbFo8c/x+cIxiQtE5G3j9NgRh2dpUDimqz6V2Lzk405v0An eD5hNhz9959E0lHaIYVqYx9aeQOpDOBNLBax8r4QM4XLwfqR/i/yonTPZNTD33SP9+W9 TjEA== 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=fhnFO/AgiUnpVe/kOO8qr/fk5V+Vs0bVv0iWqS3BYVI=; b=i3twO/Mg5vbLxGCNr4JwRf6WGy8mYZ//dgELaTMfldVCRRPUUckAN9CGCGEOo6eZtc cKzw77eq2UpgykygrrKSqz5HwgwpIY9dQlo1buSblBujYpYZMLhc0heTUzFEO2ZKDPdJ /Ik4Rwu/6CgZ6F3PlRzKK0N3nLMI+jFMCvzw6uPxNWk+vQ2ysfDV/wM77StIwHjYSc2n 8c0vABhkHPFWUwT7s1SKHcYL61rxmOA+vhh3xZoJaHEQNt+AM1BzSoOje4mt6TlaFid6 QG56wl8xSNV0ee3TKXknM+TZZXFg4886weev3srWy3mMQBccQ307ajdq0xse+EpcknoC flLQ== X-Gm-Message-State: AOAM532LgLAUyDpAp2V5T5HLm5LMd9i0ZG2MXVvW3gdRK8CX/oHxinG4 5qxlOjwgEXA00m2DHsEyK951/PJ0VnPAjyejdao2zIFN X-Google-Smtp-Source: ABdhPJxIYzgW20RFDvjwBR2sJGtdI/gHLH8WEIoS1zyCxZVL9BJM2HoikuXWPH/q/ClYTTUsEDVW0dCc/KYTOV+yKNo= X-Received: by 2002:ab0:2109:: with SMTP id d9mr10668059ual.76.1607317541745; Sun, 06 Dec 2020 21:05:41 -0800 (PST) MIME-Version: 1.0 References: <20201205210351.DB78E2904420@ary.qy> <28759E60-3A00-4D25-9490-34495B96EE10@bluepopcorn.net> <9c23d850-4164-1320-1c25-40554c1f64b@taugh.com> In-Reply-To: From: "Murray S. Kucherawy" Date: Sun, 6 Dec 2020 21:05:29 -0800 Message-ID: To: Michael Thomas Cc: IETF DMARC WG Content-Type: multipart/alternative; boundary="0000000000001df86705b5d8c7f2" Archived-At: Subject: Re: [dmarc-ietf] ARC vs reject X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 07 Dec 2020 05:05:45 -0000 --0000000000001df86705b5d8c7f2 Content-Type: text/plain; charset="UTF-8" On Sun, Dec 6, 2020 at 11:02 AM Michael Thomas wrote: > Based on the work I did at Cisco 15 years ago which essentially was a > heuristic based form of those two drafts, I found that it worked for > about 90 some percent. I unfortunately do not know what the nature of > the remaining messages that could not be recovered (either I never did > the analysis or don't remember). Things may have changed some since > then, but that was what we got for the entire mail stream of a large > company. Is that "good enough"? Or better yet, what is the definition of > "good enough"? > A counter-argument I've heard often to the idea of reversible transformations is that it can become a spam vector, no different than the argument against "l=". For instance, if we start chopping off typical list signatures ("delete everything at and after the lowest line containing only hyphens"), then I can take a message from a good actor, tack a spam list signature onto it, claim I'm an MLM, and it'll still pass with the author domain signature when it gets delivered downstream, though the spam will still be there. Another is that it's not actually easy to describe all or even most of the mutations an MLM might make to a message. (Mailman sent me the list of changes they might make to a message. It's not a small list.) Yet another is that two different MLMs might implement MIME-izing actions ever so slightly differently, yet both results are fully compatible with MIME and indistinguishable when rendered by most MUAs. So in the limit, this comes down to defining a set of transformations everyone agrees are allowed, and then all MLMs and filters implementing exactly those and no more. There doesn't seem to be much of an appetite in the community for this path. -MSK --0000000000001df86705b5d8c7f2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sun, Dec 6, 2020 at 11:02 AM Michael T= homas <mike@mtcc.com> wrote:
=
Based on the work I did at Cisco 15 years ago which essentially was= a
heuristic based form of those two drafts, I found that it worked for
about 90 some percent. I unfortunately do not know what the nature of
the remaining messages that could not be recovered (either I never did
the analysis or don't remember). Things may have changed some since then, but that was what we got for the entire mail stream of a large
company. Is that "good enough"? Or better yet, what is the defini= tion of
"good enough"?

A counter-argu= ment I've heard often to the idea of reversible transformations is that= it can become a spam vector, no different than the argument against "= l=3D".=C2=A0 For instance, if we start chopping off typical list signa= tures ("delete everything at and after the lowest line containing only= hyphens"), then I can take a message from a good actor, tack a spam l= ist signature onto it, claim I'm an MLM, and it'll still pass with = the author domain signature when it gets delivered downstream, though the s= pam will still be there.

Another is that it= 9;s not actually easy to describe all or even most of the mutations an MLM = might make to a message.=C2=A0 (Mailman sent me the list of changes they mi= ght make to a message.=C2=A0 It's not a small list.)

Yet another is that two different MLMs might implement MIME-izing ac= tions ever so slightly differently, yet both results are fully compatible w= ith MIME and indistinguishable when rendered by most MUAs.

So in the limit, this comes down to defining a set of transformat= ions everyone agrees are allowed, and then all MLMs and filters implementin= g exactly those and no more.=C2=A0 There doesn't seem to be much of an = appetite in the community for this path.

-MSK
<= /div>
--0000000000001df86705b5d8c7f2-- From nobody Sun Dec 6 21:15: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 A05C33A100D for ; Sun, 6 Dec 2020 21:15:47 -0800 (PST) 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 9c03YABzWLJa for ; Sun, 6 Dec 2020 21:15:46 -0800 (PST) Received: from mail-ua1-x931.google.com (mail-ua1-x931.google.com [IPv6:2607:f8b0:4864:20::931]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E4A2E3A100C for ; Sun, 6 Dec 2020 21:15:45 -0800 (PST) Received: by mail-ua1-x931.google.com with SMTP id s23so1232382uaq.10 for ; Sun, 06 Dec 2020 21:15:45 -0800 (PST) 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=Qfrpw2o6kFZx4+WoOa9W9LA1ckoTGUPZWHp2ROCoQ8s=; b=qAUciJrke/o+VBIjm0EzbTaNgmWv/z6vYswbiClFpcPzmH3lZbVXaVwXSBkW314+kW F886BRBBNjiQyjwW6JjMXMctcMdFNOZ/DjOBplpxdIw3VcCadQdN1V/pe/5sbGfD/qHq kCDhp5e30lNl4WW0s3x6I/uqp3112ZjSGz2BPBd9HMmLL/ee7Z1sdbFrXpsdrD7S4kG4 fE4BOM10QE5jfmPMa9quaBzkh7pavrRr67n+LsnfSoSL/m4EwVN/UjP7u6psVuiPpfpc cDhlluY+DnLWQam/P9U7pPIeuEbRHWqioxqMbHfJyy6pXek9az0seeKxJO8ensCUjNmD jfkw== 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=Qfrpw2o6kFZx4+WoOa9W9LA1ckoTGUPZWHp2ROCoQ8s=; b=Gs1R9bAE+/eRcAYEx0fbKul6OQtVNnGL/r+UYlDNAJWUoQm/tCVJ1/uuVvAULwNCtT igknaKthg6274venWhxLRvtMuxpWBAIHVx3apauHT3QG2EXzhbVV/FXtK2FxhH9U4azg eRm9py+jX5Uk41tx/Ywdwdhv1Ggz6b5YYtBu3AmeyAwNt6wijYEa3fC0h9gaRzKoMVas 59KKLJ8KClO1SITf1s32kF0UFZhL0mC/5QLURXYq4tOki9vnKnTwKiICHbaR1twcFtuN ZF1mxr4+1HEa4VGx7V5MmxKt+fkIySVuTyOAmrZiB0XKmhyhtkrGyqKHzU4ahFNenIof TqKA== X-Gm-Message-State: AOAM533Au6zQqO0+hS6+Nbd48j74Ai+PciQBnhBKjeQiCRqIURWP9it9 /Zs81CZE+VM604Y/3/zExYV/b7RMigw1U29Sx7udUK4+ X-Google-Smtp-Source: ABdhPJxcMuktbHy2VPHOB8EkSHF44k9vcqjEsl9G99VmRWPH6GPDNcnQp0uhv/BrXw/xPDgQB3wMKsufUP9vDhxqdRw= X-Received: by 2002:ab0:2997:: with SMTP id u23mr4965951uap.67.1607318144661; Sun, 06 Dec 2020 21:15:44 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: "Murray S. Kucherawy" Date: Sun, 6 Dec 2020 21:15:32 -0800 Message-ID: To: Douglas Foster Cc: IETF DMARC WG Content-Type: multipart/alternative; boundary="0000000000000dbac405b5d8eb1a" Archived-At: Subject: Re: [dmarc-ietf] DMARC and ARC X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 07 Dec 2020 05:15:48 -0000 --0000000000000dbac405b5d8eb1a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Dec 4, 2020 at 7:58 PM Douglas Foster < dougfoster.emailstandards@gmail.com> wrote: > First, lets begin with the obvious: malicious messages come from > enterprises that are in the malicious message business. They rarely sen= d > just one message, and their content changes continually. Therefore, my > priority is to block malicious sources. Messages that are correctly > blocked on content, rather than source, are the canary-in-the-mine which > warns me that my sender blocks need to be tightened. > I was under the impression from my work in the anti-spam world that sources also change. It's trivial to come from a new IP address or sign with a new domain name when I think you're blocking me. Thus, negative reputations are generally not useful to accumulate long term. On the contrary, the thing that's mostly reliable is static sources that have good reputations, because they tend to remain (mostly) static, and they work to preserve their reputations. I tend to give them preferential treatment. If a message is not forwarded, every organization involved in its delivery > is assumed to have a relationship to the sender and therefore a shared > responsibility for the final product. DMARC, SPF, and many spam filters > assume that the adjacent MTA is the only source that needs to be evaluate= d. > This seems overly general. A message going from A to B to C to me here at Gmail means Gmail has a relationship with A? Forwarding introduces an intermediary organization which presumably > operates on behalf of the recipient, rather than the sender. It is not > involved in the creation of the message and has no economic relationship > with most of the message sources. More importantly, because it will be > forwarding messages from sources with a variety of reputations, the > forwarder will be perceived as having a very unreliable reputation =E2=80= =93 > sending both very much unwanted content and very much wanted content from > the same or overlapping identifiers. SPF and DMARC force the forwarder = to > reliably identify itself, but in this process, they force the forwarder t= o > hide information that the receiving MTA needs for proper message > filtering. This aggravates any effort to filter based on original-source > identity. > I'm also confused here, because it's ambiguous what you mean by Forwarder. Some forwarders simply replace the envelope and send the message on its way with no body modifications and only trace header field changes. They don't meet the definition you're describing because no details are hidden. Others, like MLMs, may mutate the message and re-post it, but I would argue that's not forwarding, that's a new message; the list is the originator. -MSK --0000000000000dbac405b5d8eb1a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Fri, Dec 4, 2020 at 7:58 PM Douglas Fo= ster <dougfoster.= emailstandards@gmail.com> wrote:
First, = lets begin with the obvious:=C2=A0=C2=A0 malicious messages come from enter= prises that are in the malicious message business.=C2=A0=C2=A0 They rarely send just one message, and their content changes continually.= =C2=A0=C2=A0 Therefore, my priority is to block malicious sources.=C2=A0=C2=A0 Messages that are correctly blocked on content, rather than source, are the canary-in-the-mine which wa= rns me that my sender blocks need to be tightened.

I was under the impression from my w= ork in the anti-spam world that sources also change.=C2=A0 It's trivial= to come from a new IP address or sign with a new domain name when I think = you're blocking me.=C2=A0 Thus, negative reputations are generally not = useful to accumulate long term.=C2=A0 On the contrary, the thing that's= mostly reliable is static sources that have good reputations, because they= tend to remain (mostly) static, and they work to preserve their reputation= s.=C2=A0 I tend to give them preferential treatment.

If a message is not forwarded, every org= anization involved in its delivery is assumed to have a relationship to the sender and therefore = a shared responsibility for the final product.=C2=A0=C2=A0 DMARC, SPF, and many spam filters assume that the adjacent MTA is the only source that needs to be evaluated.

This seems overly general.=C2=A0 A message goin= g from A to B to C to me here at Gmail means Gmail has a relationship with = A?

Forwarding intr= oduces an intermediary organization which presumably operates on behalf of the recipient, rather than the sender.=C2=A0=C2=A0 It= is not involved in the creation of the message and has no economic relationship with most of the message sources.=C2=A0=C2=A0 More importantly, because it will be forwarding messages from sources with a variety of reput= ations, the forwarder will be perceived as having a very unreliable reputation =E2= =80=93 sending both very much unwanted content and very much wanted content from t= he same or overlapping identifiers.=C2=A0=C2=A0 SPF and DMARC force the forwarder to reliably identify itself, but in this process, they force the forwarder to hide information that the receiving MTA needs f= or proper message filtering.=C2=A0 This aggravates any effort to filter based = on original-source identity.

I'm also confus= ed here, because it's ambiguous what you mean by Forwarder.=C2=A0 Some = forwarders simply replace the envelope and send the message on its way with= no body modifications and only trace header field changes.=C2=A0 They don&= #39;t meet the definition you're describing because no details are hidd= en.=C2=A0 Others, like MLMs, may mutate the message and re-post it, but I w= ould argue that's not forwarding, that's a new message; the list is= the originator.

-MSK
--0000000000000dbac405b5d8eb1a-- From nobody Sun Dec 6 21:19: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 3A20D3A1043 for ; Sun, 6 Dec 2020 21:18:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.851 X-Spam-Level: X-Spam-Status: No, score=-1.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iecc.com header.b=FmFU4CRv; dkim=pass (2048-bit key) header.d=taugh.com header.b=A7F+b7Ne Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id djtCJGL9CAnx for ; Sun, 6 Dec 2020 21:18:50 -0800 (PST) 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 7A50C3A103C for ; Sun, 6 Dec 2020 21:18:49 -0800 (PST) Received: (qmail 62502 invoked from network); 7 Dec 2020 05:18:47 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=f423.5fcdbb37.k2012; bh=6rJK0UkQmECYNsgFgojoCe0SKHCVgbAsfs+yJKeYOF0=; b=FmFU4CRvqTqwxNHDBDCv4RUNnjdiDCZqJnUqg0f+wB0qHJ4K0aV0K7ateZv3Lg4VRa57Ver6ASHYf2Sdw18p7gLvyPmRxUYjVxA5PFMWQgS4MsZQ5bOwXSEkvjwVZsZMWuMiAOndsTvr4UiYzT9POPe4xjLAmV1lNYkNREYNGsUICTK/pRfGAyPjFF1ISFvBHWjERbmHsHsSJHH4npHIkO9PSaZEyjYjnugwQueO8idPyt0BpnIyNOSCTBXe292IwMQMy7fZD8Pgi5n+2otPhcjCn3NxM08OZzlvrRuoN+4S4D6TxusLjRSLZNB9DVs3/BF1YD+UUP9dl5IxW/TQmw== DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=f423.5fcdbb37.k2012; bh=6rJK0UkQmECYNsgFgojoCe0SKHCVgbAsfs+yJKeYOF0=; b=A7F+b7Ne/0Z3CELEQUYw12ZrqEwVvXjtLL2pRM6HXH/cjmjJGaCGA8LWQUAup5Qh7WWtSR6yYK4DssQyGUpbS+mfLY4rLPFFYMlxPqGfnycmF5NXDjw0QNBtJ6cNA+Q8ksRF2FOJekGsVLYX27KTVhz1pE2C1k96XobrnCVbtid+YSAZQZHQ7zIKeK8qKJAERdX+c2CHmobVFW3Ckk4gdn4LOB/Fos4HQf8QrOqqsVmiNIMesdykyuuJZencIOM87pvREOww84p4YwBow+NAQs2MXAcRHK72TYcw7krtXSfNnlRO8RzdXwMQ04za7qByl2Brp0roNjV098LBF3UCOQ== 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; 07 Dec 2020 05:18:47 -0000 Received: by ary.qy (Postfix, from userid 501) id CBEEE291CC3F; Mon, 7 Dec 2020 00:18:46 -0500 (EST) Date: 7 Dec 2020 00:18:46 -0500 Message-Id: <20201207051846.CBEEE291CC3F@ary.qy> From: "John Levine" To: dmarc@ietf.org Cc: superuser@gmail.com In-Reply-To: Organization: Taughannock Networks X-Headerized: yes Cleverness: minimal Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] not ADSP, was is DMARC informational? X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 07 Dec 2020 05:18:59 -0000 In article you write: >As I recall, people took a run at trying ADSP and it was largely >unsuccessful. I recall at least Yahoo, PayPal, and Google trying it but >finding that it interfered with their employees' participation in lists, so >they each invented new domains for their employees to use as separate from >their operational public services. This basically led to its demise. Among ADSP's shortcomings was that there was no way to test it other than to turn it on and see how much damage it caused. The answer was frequently a lot, so they turned it back off and that was that. DMARC certainly has its problems but the reporting is great. It makes the surprises when you turn DMARC on a lot less, at least if your name is not AOL or Yahoo. R's, John From nobody Sun Dec 6 21:24: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 0C6DB3A1011 for ; Sun, 6 Dec 2020 21:24:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.65 X-Spam-Level: X-Spam-Status: No, score=-1.65 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, 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=mtcc-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EAvqz72fbcXy for ; Sun, 6 Dec 2020 21:24:02 -0800 (PST) Received: from mail-pf1-x42e.google.com (mail-pf1-x42e.google.com [IPv6:2607:f8b0:4864:20::42e]) (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 489913A1010 for ; Sun, 6 Dec 2020 21:24:01 -0800 (PST) Received: by mail-pf1-x42e.google.com with SMTP id 11so2422029pfu.4 for ; Sun, 06 Dec 2020 21:24:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mtcc-com.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=KD2ghDNIU1iFdKOLVtWD1SF+ju37ububLWGQAArygQg=; b=xD9IngQA84P5QgS3ic162y23KOQv2j0SrfOnNtgbZd2IibuwgQ2gPMzurDhf4s5mYG ozxZzUy25zucOyznKx63BP1N4TchR0kyM0LUa6Sduoo3PpK39mTrgGh6pAbJjDhtTxIV VO/8gL/Fyjnl2/m0veRMkJuniIZU49iHHV8F2HmwFWojJhbIU06/4kRBHkp2W7LYEFlw msqgxxQRHNZx0GSRfL6I7T+JdcZBCcOvrPT0QwFv8Q3AZ25Jz+nruP64UblcqxUHbO6e jBP3lsDN3XacJxOHrhiBEQ61X5tgaPVaHas5BZVLQ7/zJg88dnCPwe74oIGBAYKK0v/R LSZg== 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=KD2ghDNIU1iFdKOLVtWD1SF+ju37ububLWGQAArygQg=; b=GrVSGw0UYfHBp77C5fmWqjUZ0aLOONPr5b5l+NUqVlCfOcTk1ruSVZutVecMLKjXFt g+SmX3vIM4lB+NrZTYITjc/A5tGMfrY44Js18X8jfDwLf4MBmenqx7pgSVGJFCw7OHP5 9ITEGFQ2PB3ZB4M1B4pvnCLfwp2N3wzes+etAEp3m398vbg1CYnuOBHuB/btdDfpPL6k 4lfAr6jUVDmmEPL8pMl2RJZv0yb9NUvQUHeTmbVy0JZmTlVM3QhMonFTMQl69POav/uq g++ayFHsyVgGTneWAguWv4E2mdFyvvNoeNjiQhXYjRVXXrxSwA1RJyphn2GJ4Q57DnYw wReg== X-Gm-Message-State: AOAM5314PawCXJilqxEFUU8u/mZ8CiXtsELxlyT1y+k2Fy1lH4ZUudks R1R20TzRepFHY6EOOeIAxQEGuBIBKi2FuQ== X-Google-Smtp-Source: ABdhPJw6yCtlE6FHTh2/Zbzcq4/Z+BoxfdzyKIJd5F+Bf2zqluJta8Z2RBFfIdYF/EHXlUF4FHocsA== X-Received: by 2002:a17:902:9341:b029:d9:e385:bca2 with SMTP id g1-20020a1709029341b02900d9e385bca2mr14571526plp.64.1607318640699; Sun, 06 Dec 2020 21:24:00 -0800 (PST) Received: from mike-mac.lan (107-182-42-108.volcanocom.com. [107.182.42.108]) by smtp.gmail.com with ESMTPSA id a11sm12671486pfc.31.2020.12.06.21.23.59 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 06 Dec 2020 21:24:00 -0800 (PST) To: "Murray S. Kucherawy" Cc: IETF DMARC WG References: <20201205210351.DB78E2904420@ary.qy> <28759E60-3A00-4D25-9490-34495B96EE10@bluepopcorn.net> <9c23d850-4164-1320-1c25-40554c1f64b@taugh.com> From: Michael Thomas Message-ID: Date: Sun, 6 Dec 2020 21:23:58 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------50CC5010E15FE30B598E3ED0" Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] ARC vs reject X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 07 Dec 2020 05:24:04 -0000 This is a multi-part message in MIME format. --------------50CC5010E15FE30B598E3ED0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 12/6/20 9:05 PM, Murray S. Kucherawy wrote: > On Sun, Dec 6, 2020 at 11:02 AM Michael Thomas > wrote: > > Based on the work I did at Cisco 15 years ago which essentially was a > heuristic based form of those two drafts, I found that it worked for > about 90 some percent. I unfortunately do not know what the nature of > the remaining messages that could not be recovered (either I never > did > the analysis or don't remember). Things may have changed some since > then, but that was what we got for the entire mail stream of a large > company. Is that "good enough"? Or better yet, what is the > definition of > "good enough"? > > > A counter-argument I've heard often to the idea of reversible > transformations is that it can become a spam vector, no different than > the argument against "l=".  For instance, if we start chopping off > typical list signatures ("delete everything at and after the lowest > line containing only hyphens"), then I can take a message from a good > actor, tack a spam list signature onto it, claim I'm an MLM, and it'll > still pass with the author domain signature when it gets delivered > downstream, though the spam will still be there. > > Another is that it's not actually easy to describe all or even most of > the mutations an MLM might make to a message. (Mailman sent me the > list of changes they might make to a message.  It's not a small list.) > > Yet another is that two different MLMs might implement MIME-izing > actions ever so slightly differently, yet both results are fully > compatible with MIME and indistinguishable when rendered by most MUAs. > > So in the limit, this comes down to defining a set of transformations > everyone agrees are allowed, and then all MLMs and filters > implementing exactly those and no more. There doesn't seem to be much > of an appetite in the community for this path. > An idea that i've been rolling around in my head is that the MLM could give a sed-like script to rollback the changes. since they know their modifications, they can obviously express how to unmodify them. it may have less issue with the mime hackery you were thinking about. But as far as your point about spam vectors it is surely just as true about ARC, right? at least with recovering the original text i have the ability to remove all of the transforms and deliver the original text.  ARC not so much. it's all or nothing on the trust front. But I really think the key thing about all of this is figuring out what defines success. That is the most important thing by far. Mike --------------50CC5010E15FE30B598E3ED0 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit


On 12/6/20 9:05 PM, Murray S. Kucherawy wrote:
On Sun, Dec 6, 2020 at 11:02 AM Michael Thomas <mike@mtcc.com> wrote:
Based on the work I did at Cisco 15 years ago which essentially was a
heuristic based form of those two drafts, I found that it worked for
about 90 some percent. I unfortunately do not know what the nature of
the remaining messages that could not be recovered (either I never did
the analysis or don't remember). Things may have changed some since
then, but that was what we got for the entire mail stream of a large
company. Is that "good enough"? Or better yet, what is the definition of
"good enough"?

A counter-argument I've heard often to the idea of reversible transformations is that it can become a spam vector, no different than the argument against "l=".  For instance, if we start chopping off typical list signatures ("delete everything at and after the lowest line containing only hyphens"), then I can take a message from a good actor, tack a spam list signature onto it, claim I'm an MLM, and it'll still pass with the author domain signature when it gets delivered downstream, though the spam will still be there.

Another is that it's not actually easy to describe all or even most of the mutations an MLM might make to a message.  (Mailman sent me the list of changes they might make to a message.  It's not a small list.)

Yet another is that two different MLMs might implement MIME-izing actions ever so slightly differently, yet both results are fully compatible with MIME and indistinguishable when rendered by most MUAs.

So in the limit, this comes down to defining a set of transformations everyone agrees are allowed, and then all MLMs and filters implementing exactly those and no more.  There doesn't seem to be much of an appetite in the community for this path.


An idea that i've been rolling around in my head is that the MLM could give a sed-like script to rollback the changes. since they know their modifications, they can obviously express how to unmodify them. it may have less issue with the mime hackery you were thinking about.

But as far as your point about spam vectors it is surely just as true about ARC, right? at least with recovering the original text i have the ability to remove all of the transforms and deliver the original text.  ARC not so much. it's all or nothing on the trust front.

But I really think the key thing about all of this is figuring out what defines success. That is the most important thing by far.

Mike

--------------50CC5010E15FE30B598E3ED0-- From nobody Sun Dec 6 21:30: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 1912D3A1011 for ; Sun, 6 Dec 2020 21:30:43 -0800 (PST) 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 75v8pWY07WBD for ; Sun, 6 Dec 2020 21:30:41 -0800 (PST) Received: from mail-vs1-xe2a.google.com (mail-vs1-xe2a.google.com [IPv6:2607:f8b0:4864:20::e2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B56CB3A0CEF for ; Sun, 6 Dec 2020 21:30:41 -0800 (PST) Received: by mail-vs1-xe2a.google.com with SMTP id x26so6928445vsq.1 for ; Sun, 06 Dec 2020 21:30:41 -0800 (PST) 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=K2yGdNgthQwKEDk0TPDCw9I74WzRUEX1lUch4QC1+vI=; b=s8SNQe9Da5LDUkqCmgn3ZWSEYKO1HR6a68RWi7EbP42H/UoO2gT/eiTrGYDNgVwxpP NZNzj1DELZ6xvLsg9n+zVwAPWPIhQIZ6iGGSyEW6G9BIwg0t4+MSIRLfeOGUhLIDEcra YrwsIwG2LxZk+sVG8ln3LNyJZoAq0KUAwYZzyGUYtGzZVq1fQrgeuCQFo9vo/koLmshr qemWtsntNWPENpbE6NoRST0dICpXpFpfdRK46kx9PFGVDCljrv/Tu6105UIh2N6H681x YPvaZOoMGygor5o2iMVTb8jF1rIHdDs/boy2Hb3bBo5NuSXlaUDCQMalO3tZzuIvitWY 31Kg== 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=K2yGdNgthQwKEDk0TPDCw9I74WzRUEX1lUch4QC1+vI=; b=W94OQjXFg/+8Mv2zGCb2YEFzhVZAKoU00M+pCH+ii8TKdURVA89N54i6QBonMv+810 w3ZE2U1L7jZkuN636T6P0VPmR8LHlYkU1vqtWSCqS5HzVDBQk/9JyqXrRd5pAfM4iYPY pDSlrYdORtFddZd8DbCmn86oO+lh0irc0lAs6qNUymzyPAQjyODppXEXYf98MJeWaFhd Rv0b1y01beFyogdlJlu2Bxhbe5v1ViY1UhnGV57ocvLHrh/LSFFO/mRRW0kl82uqHUK3 TqWx9zQRqmUHwJyPm5J/+mqxfM20Rb7W5YgEbzyMGxjkIj0EQFpo0YvAz2Sd5HTafkJO O6sA== X-Gm-Message-State: AOAM533NDjgK5pREjCX6/BxWCcAI7C63uZXwJjG60SejPHKUJ6W9ieH+ DGVwF9mV6qkOTXUSjTjS/47IICOM0XGTQ87JBxI= X-Google-Smtp-Source: ABdhPJwljpwFZCH6en+6EzTqqCJ6g2PlybRb/GluK3ws3M6olODOTsnEke7EWEOKsJZ73DNuOLpxo2cENunVob5wl2Q= X-Received: by 2002:a67:f7c8:: with SMTP id a8mr10728136vsp.54.1607319040517; Sun, 06 Dec 2020 21:30:40 -0800 (PST) MIME-Version: 1.0 References: <20201205210351.DB78E2904420@ary.qy> <28759E60-3A00-4D25-9490-34495B96EE10@bluepopcorn.net> <9c23d850-4164-1320-1c25-40554c1f64b@taugh.com> In-Reply-To: From: "Murray S. Kucherawy" Date: Sun, 6 Dec 2020 21:30:28 -0800 Message-ID: To: Michael Thomas Cc: IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000736b6605b5d920ea" Archived-At: Subject: Re: [dmarc-ietf] ARC vs reject X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 07 Dec 2020 05:30:43 -0000 --000000000000736b6605b5d920ea Content-Type: text/plain; charset="UTF-8" On Sun, Dec 6, 2020 at 9:24 PM Michael Thomas wrote: > An idea that i've been rolling around in my head is that the MLM could > give a sed-like script to rollback the changes. since they know their > modifications, they can obviously express how to unmodify them. it may have > less issue with the mime hackery you were thinking about. > You'd need a way to assert, and then evaluate, that something equivalent to "s/.*/spam/g" is a transformation you're not willing to reverse and say "yep, we're good." I don't know how you'd go about automating that. > But as far as your point about spam vectors it is surely just as true > about ARC, right? at least with recovering the original text i have the > ability to remove all of the transforms and deliver the original text. ARC > not so much. it's all or nothing on the trust front. > > But I really think the key thing about all of this is figuring out what > defines success. That is the most important thing by far. > I think ARC, like PSD, is meant to run for a while and see what we've learned from it. Maybe it's the silver bullet, or maybe it's ineffective complexity. That should be part of the experiment's definition; Section 11 of the ARC RFC does try to capture all of that. -MSK --000000000000736b6605b5d920ea Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sun, Dec 6, 2020 at 9:24 PM Michael Th= omas <mike@mtcc.com> wrote:
<= /div>
=20 =20 =20
An idea that i've been rolling around in my head is that the MLM could give a sed-like script to rollback the changes. since they know their modifications, they can obviously express how to unmodify them. it may have less issue with the mime hackery you were thinking about.

You= 9;d need a way to assert, and then evaluate, that something equivalent to &= quot;s/.*/spam/g" is a transformation you're not willing to revers= e and say "yep, we're good."=C2=A0 I don't know how you&#= 39;d go about automating that.
=20

But as far as your point about spam vectors it is surely just as true about ARC, right? at least with recovering the original text i have the ability to remove all of the transforms and deliver the original text.=C2=A0 ARC not so much. it's all or nothing on the = trust front.

But I really think the key thing about all of this is figuring out what defines success. That is the most important thing by far.

I think ARC, like PSD, is meant to run for a w= hile and see what we've learned from it.=C2=A0 Maybe it's the silve= r bullet, or maybe it's ineffective complexity.=C2=A0 That should be pa= rt of the experiment's definition; Section 11 of the ARC RFC does try t= o capture all of that.

-MSK
--000000000000736b6605b5d920ea-- From nobody Sun Dec 6 21:31:12 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CDF53A1015 for ; Sun, 6 Dec 2020 21:31:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.652 X-Spam-Level: X-Spam-Status: No, score=-1.652 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mtcc-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KSb5qeYXSQMI for ; Sun, 6 Dec 2020 21:31:09 -0800 (PST) Received: from mail-pg1-x529.google.com (mail-pg1-x529.google.com [IPv6:2607:f8b0:4864:20::529]) (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 0AFE23A1013 for ; Sun, 6 Dec 2020 21:31:08 -0800 (PST) Received: by mail-pg1-x529.google.com with SMTP id e23so7928837pgk.12 for ; Sun, 06 Dec 2020 21:31:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mtcc-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=y578QlIZ4NWaOT6xjBDyWUhSeQe7ppz131l66z6AHUI=; b=DlceJTAsjsABqQRILuqbmkQjjC7xcPTau4pGUExz5AhJ5V4dinRqqla2klumPxfutL swMKTSG5hEVUJFDjHlEFx6L4q58wswLhUQwirASpYCfpNCQkoUsA/jsYOumZSbkSIFvS 2IkBM2bQRTTaEiYPw7ds32QlKfBoEyDWqbYmZcIklCr3Sx4cm/jJhHvrTRPcXMZwNJ1/ VqBxplLfJODgZ8h0cYg5Ky/Qb/2K2Kq1q8iFK0zDm5Q0HKPWxNebFEY9bMH+aOeNYnz9 Gb+MZOqqk8AEhFjPIwICpHz2Fi1y1hE0WWCa9H00FrofNtnMnP7a9by0WO9fiOxDD2DV k1eQ== 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=y578QlIZ4NWaOT6xjBDyWUhSeQe7ppz131l66z6AHUI=; b=DOzr0wIz6C6Bjk6fy9Qkk4W+3m3ytpM6IGJXGnIZwuWfVpyRY0x7Y4osJh025aC3qQ E06DS2Ht8oGSYLza7X19pEhUM695iMIcIUZkn4PUa8UxzdpOLm/zNiidHIHZUxn891sQ w8AK1lNc78+pb+8Ny3WIpmiD4ACOB3hYFq805QViUcMl8jxONfLmU7Rsed96hsLjBrBw z5icb8XEwApsCy2xcAXyJGLVXFsy4v/CIzUPJ6sk2ubqeo6c0t6SSWUmXF7T7xm16dNf n8giFjrYuMGl1OLRl24YqXCcY5NT8geME/0O5i0zk58kKQ06fBSh979n29bfd+D38QD1 89jA== X-Gm-Message-State: AOAM530GGRFPA70zofvZs3RI97m+xDVC53MDjySAWn+CxVPdwkErPhDf tf2cHyolMI0TamMaDukQwZ2oszlCOzd72g== X-Google-Smtp-Source: ABdhPJz/FSSTtN6wsgxUTtFpI0aSac9U3CJEEdVoSdrSgTl1MK67X8AJk//froRweQWnZQMeoTZwJw== X-Received: by 2002:a63:5b23:: with SMTP id p35mr17006888pgb.143.1607319068011; Sun, 06 Dec 2020 21:31:08 -0800 (PST) Received: from mike-mac.lan (107-182-42-108.volcanocom.com. [107.182.42.108]) by smtp.gmail.com with ESMTPSA id o189sm6815739pfd.73.2020.12.06.21.31.06 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 06 Dec 2020 21:31:07 -0800 (PST) To: dmarc@ietf.org References: <20201207051846.CBEEE291CC3F@ary.qy> From: Michael Thomas Message-ID: Date: Sun, 6 Dec 2020 21:31:05 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 MIME-Version: 1.0 In-Reply-To: <20201207051846.CBEEE291CC3F@ary.qy> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] not ADSP, was is DMARC informational? X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 07 Dec 2020 05:31:12 -0000 On 12/6/20 9:18 PM, John Levine wrote: > In article you write: > >> As I recall, people took a run at trying ADSP and it was largely >> unsuccessful. I recall at least Yahoo, PayPal, and Google trying it but >> finding that it interfered with their employees' participation in lists, so >> they each invented new domains for their employees to use as separate from >> their operational public services. This basically led to its demise. > Among ADSP's shortcomings was that there was no way to test it other > than to turn it on and see how much damage it caused. The answer was > frequently a lot, so they turned it back off and that was that. > > DMARC certainly has its problems but the reporting is great. It makes > the surprises when you turn DMARC on a lot less, at least if your name > is not AOL or Yahoo. but apparently y! is doing DMARC in the face of its inadequacies anyway. i really like the reporting capabilities as an auditing tool as well, but it doesn't change much on the ground with the basic problems. it just confirms that it's a bad idea to use p=reject in many cases. there are clearly many use cases where that isn't a problem -- like bank transactional mail -- and ADSP was just fine for that. nothing much has changed on that front in 15 years. I find it amusing to be talking about this all these years later, with all kinds of companies trying to capitalize on the new and mostly unimproved dmarc. Mike From nobody Sun Dec 6 21:42: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 DCB893A102F for ; Sun, 6 Dec 2020 21:42:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.65 X-Spam-Level: X-Spam-Status: No, score=-1.65 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, 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=mtcc-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BbKSNf7b_Sr9 for ; Sun, 6 Dec 2020 21:42:56 -0800 (PST) Received: from mail-pf1-x42b.google.com (mail-pf1-x42b.google.com [IPv6:2607:f8b0:4864:20::42b]) (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 6C43F3A102C for ; Sun, 6 Dec 2020 21:42:56 -0800 (PST) Received: by mail-pf1-x42b.google.com with SMTP id q22so8661570pfk.12 for ; Sun, 06 Dec 2020 21:42:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mtcc-com.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=uq4K/DSQLryadT078aK+L5Jq+JuwZ0Ly5quePRCyNps=; b=spIEEBloiQcUJ6haJvcJ14skr7ph0xjWESZd2HN1sT8d14QPyXTquNzM4HALVy/yWO 9bIU121nEzmhXELyJ+an9Mi22qqEtjDc2eLpVz+G+NfMM82IcwcyIcLe89Vx75aOkU68 SEX5RmyqrmgsyhLhTi6gfybplrpTyz43HnWjcnZhF9KniLhxzLXNtX76WJqTaK0W2SVw t4Jzpk+VV1PAxA7mL0lbrPPZG4VsJRGDai6qHGYgrsXD2yl0vuV4mM6ttYdzx+EdILwd g3pDJHyZi+8+/13GVGQvcV4Z2BjZmOT09yQvfwxvetnRvvDBEbIX3dE67AwoLuZlMDiR nK0Q== 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=uq4K/DSQLryadT078aK+L5Jq+JuwZ0Ly5quePRCyNps=; b=KxPegVWktZQZ6ZzzKHSUNgNpG625iJbcpiJv93IE3o/svMtlacJ8oJLpIEYmbk/gr3 PNlxW1MGyEhBskNlhWxszMsW44IXakV6cj4NZXBPbD2MKstYQ6lQki5Pj39dz22Z3vqv nbyUueLbHr/BcTSo09S4MTtOYyVMtlJJJ+yh+hPnTI+NwMeC3dBv+Ww7BmLkdiR3Yr8O n0RxlD5aFpgT+WWIsLTHTzSNkBj2eZhTEaoelnkLzlOXB3Izv5QNS+KC3DnblR8TfjE4 8PcRsSilI2PixuE75H74J+4L5h+GOCscBwn8sAE4LWwT/MkVydZVirYbOboFT244MQTa Tqpg== X-Gm-Message-State: AOAM533aetbWTmuq/iOfiPkjfM3hoL7H8Y+8hdvlA4TSaqPEZHOc3/VA vfrTEAikIW9P+qwKcnYoLYJBS7RFpTIqTA== X-Google-Smtp-Source: ABdhPJzAl13W2bKXcLibOwlKYX4uDqrpE7QDISsESVBa1Ey7zbW8olkJUlYQHr4YhWrkql2Inh1IrQ== X-Received: by 2002:a17:902:a502:b029:da:f580:bc35 with SMTP id s2-20020a170902a502b02900daf580bc35mr3804118plq.60.1607319775292; Sun, 06 Dec 2020 21:42:55 -0800 (PST) Received: from mike-mac.lan (107-182-42-108.volcanocom.com. [107.182.42.108]) by smtp.gmail.com with ESMTPSA id f9sm2558137pfa.41.2020.12.06.21.42.53 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 06 Dec 2020 21:42:54 -0800 (PST) To: "Murray S. Kucherawy" Cc: IETF DMARC WG References: <20201205210351.DB78E2904420@ary.qy> <28759E60-3A00-4D25-9490-34495B96EE10@bluepopcorn.net> <9c23d850-4164-1320-1c25-40554c1f64b@taugh.com> From: Michael Thomas Message-ID: <5ece3b4d-bdc4-ca57-d54a-3186efac8007@mtcc.com> Date: Sun, 6 Dec 2020 21:42:52 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------A9DC0C038C0FCC8277F26C4C" Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] ARC vs reject X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 07 Dec 2020 05:42:58 -0000 This is a multi-part message in MIME format. --------------A9DC0C038C0FCC8277F26C4C Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 12/6/20 9:30 PM, Murray S. Kucherawy wrote: > On Sun, Dec 6, 2020 at 9:24 PM Michael Thomas > wrote: > > An idea that i've been rolling around in my head is that the MLM > could give a sed-like script to rollback the changes. since they > know their modifications, they can obviously express how to > unmodify them. it may have less issue with the mime hackery you > were thinking about. > > > You'd need a way to assert, and then evaluate, that something > equivalent to "s/.*/spam/g" is a transformation you're not willing to > reverse and say "yep, we're good."  I don't know how you'd go about > automating that. yes, definitely. but that's just as true of your draft. these are all heuristics at some level to feed into some hypothetical filtering machine to make sure there is no fuckery going on. such is the nature of spam filtering. i think that is the part that is hard thing to swallow from a standards standpoint and is what causes so much roiling. it's hard for me to say if that's a good thing or a bad thing. > But as far as your point about spam vectors it is surely just as > true about ARC, right? at least with recovering the original text > i have the ability to remove all of the transforms and deliver the > original text.  ARC not so much. it's all or nothing on the trust > front. > > But I really think the key thing about all of this is figuring out > what defines success. That is the most important thing by far. > > I think ARC, like PSD, is meant to run for a while and see what we've > learned from it.  Maybe it's the silver bullet, or maybe it's > ineffective complexity.  That should be part of the experiment's > definition; Section 11 of the ARC RFC does try to capture all of that. > As I've been harping on, we need to have an agreed on definition of success. We know that 100% is not among them. What in the long tail don't we care about? Mike --------------A9DC0C038C0FCC8277F26C4C Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit


On 12/6/20 9:30 PM, Murray S. Kucherawy wrote:
On Sun, Dec 6, 2020 at 9:24 PM Michael Thomas <mike@mtcc.com> wrote:
An idea that i've been rolling around in my head is that the MLM could give a sed-like script to rollback the changes. since they know their modifications, they can obviously express how to unmodify them. it may have less issue with the mime hackery you were thinking about.

You'd need a way to assert, and then evaluate, that something equivalent to "s/.*/spam/g" is a transformation you're not willing to reverse and say "yep, we're good."  I don't know how you'd go about automating that.


yes, definitely. but that's just as true of your draft. these are all heuristics at some level to feed into some hypothetical filtering machine to make sure there is no fuckery going on. such is the nature of spam filtering. i think that is the part that is hard thing to swallow from a standards standpoint and is what causes so much roiling. it's hard for me to say if that's a good thing or a bad thing.

But as far as your point about spam vectors it is surely just as true about ARC, right? at least with recovering the original text i have the ability to remove all of the transforms and deliver the original text.  ARC not so much. it's all or nothing on the trust front.

But I really think the key thing about all of this is figuring out what defines success. That is the most important thing by far.

I think ARC, like PSD, is meant to run for a while and see what we've learned from it.  Maybe it's the silver bullet, or maybe it's ineffective complexity.  That should be part of the experiment's definition; Section 11 of the ARC RFC does try to capture all of that.

As I've been harping on, we need to have an agreed on definition of success. We know that 100% is not among them. What in the long tail don't we care about?

Mike

--------------A9DC0C038C0FCC8277F26C4C-- From nobody Sun Dec 6 23:06: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 CC1E13A10D8 for ; Sun, 6 Dec 2020 23:06:03 -0800 (PST) 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 njKWgI2ebnNp for ; Sun, 6 Dec 2020 23:06:02 -0800 (PST) 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 88A0C3A10D4 for ; Sun, 6 Dec 2020 23:06:02 -0800 (PST) Received: by mail-ua1-x92c.google.com with SMTP id k12so4147624uae.13 for ; Sun, 06 Dec 2020 23:06:02 -0800 (PST) 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=s1snt+MPuXyDUDi7AK/wNyAtxPtxLhUdqAgnFGO9JQ0=; b=STl59UYjzAYTskOrUCSFzRDMHmVAFplSDwxh46HuQGaq55cBJRorEMBOH9AlApU8w2 WdITwHwox6E/V11llY0Q7WWLOkm94FVFF8j/RFSz2MQJh9QfKre2hORuvc6iuD0azag5 dJRTRZwPc5T1kDptuol2omfyob4Uuym2JR6sDJO7VLnpEs06Dl6kzhZ3tdSWTWugvz/E x30h+RAqZx1LdvF8/dE4p8JGnCCof3ZqKud3GVg4IwItNj107ClQ0T1uO/ksk8WjgzAn pzt8p6ahPlxeGkceTjEmbd/HO+/8AEZ2+JIfkfZnLuXh65Uag/vNEJ4y5W8P/YJZijjo FVCg== 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=s1snt+MPuXyDUDi7AK/wNyAtxPtxLhUdqAgnFGO9JQ0=; b=gdkzmywkD8CdMFS09Ay0kOBaOg6EzldMg3ASjbUYW//q7MZfnQQzktiOAAU+IgPzaR frouUaQAYyUcvkcKBiuuLX+fdrr3RyBYLODh4m2MagG3i5pF6q2uqSn+8TN0vmqCe5hq PA0cw/3FyVyCvbhJLtTeVtfjbRPRE6aeVvYX+i/6y2wPyNVp1sslVKlt+7sOwQHPQ4+p 968WX3/SEm0CPZO47Y7bQWM7UkSaBPrTsS33ktZzF+ygXRYIzYocBKltBQOXi/n9Tkyo WNAby14BdCCM4/GX005WVSj3W0317Hohxav47eN8RMYsCnM0dWm/vYVmyj8d52nW2syN gouw== X-Gm-Message-State: AOAM530LpVCP+sK9OGNbv0rGnPEGdhw/zxf0IeDbugh3XlQoQXyBqcwB gN3hvO6TLN23bBGC70n8/xKiX/dXXEro64QQVIhyOtMI X-Google-Smtp-Source: ABdhPJxusvVBmmZhpwNx1SeVsEAcl1dsCyOlZUr0RbNtiryztCFUEcHODzbUV81voViR9IJB75YvC4R79GdXjYamCxM= X-Received: by 2002:ab0:4881:: with SMTP id x1mr11059111uac.101.1607324761343; Sun, 06 Dec 2020 23:06:01 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: "Murray S. Kucherawy" Date: Sun, 6 Dec 2020 23:05:49 -0800 Message-ID: To: John R Levine Cc: IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000704af405b5da75ac" Archived-At: Subject: Re: [dmarc-ietf] Ticket #1 - SPF alignment X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 07 Dec 2020 07:06:04 -0000 --000000000000704af405b5da75ac Content-Type: text/plain; charset="UTF-8" Point of clarification: On Tue, Dec 1, 2020 at 2:17 PM John R Levine wrote: > We would like to close this ticket by Dec 15, two weeks from now, so short > trenchant comments are welcome. > > Ticket #1 is about SPF alignment. We need to replace references to 4408 > with 7408, ando clarify what if anything we do with SPF HELO checks if > [...] > The new SPF is RFC 7208, not 7408. -MSK --000000000000704af405b5da75ac Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable --000000000000704af405b5da75ac-- From nobody Sun Dec 6 23:13: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 976363A10DF for ; Sun, 6 Dec 2020 23:13:06 -0800 (PST) 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 9FKDqukxD8B5 for ; Sun, 6 Dec 2020 23:13:05 -0800 (PST) Received: from mail-ua1-x92b.google.com (mail-ua1-x92b.google.com [IPv6:2607:f8b0:4864:20::92b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E09A3A10DE for ; Sun, 6 Dec 2020 23:13:05 -0800 (PST) Received: by mail-ua1-x92b.google.com with SMTP id y26so4162895uan.5 for ; Sun, 06 Dec 2020 23:13:05 -0800 (PST) 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=lLhsT+bvPuVKAl31msZs/PT/Iw8rG7fVBDcQG/lOnEg=; b=Ho+jEi+erJMzW2LlwIWtlud15VzDpZLte1hkOl4inaCXHj3d2HG/cRiq1a0s+n7/jJ Drh4+UVOlNvDYAgdw6kfrNUFLvCZeVrYO4wv2ldComSmFpnWAyDk9FUyjs3Rz0uuLuja 9FuXZbW11EirIN6tBguHC65AYDQt5yTN5dTEypu5NwcbRPDhjbiyGkZ6jVO8uau7zjEN abQMCMQlM2Mt+0MjgF60yuSLX3p5SOxCA9UKpIOU/ciz0Y471CpGQIQrdQKnSgWZUExt U3FZGQrzKHTXPlz3kOFH/I4/e44TIbqEh5dQBMD6HUf1zmKFfCuj1GwQcQjVEWAj7v5P NnYQ== 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=lLhsT+bvPuVKAl31msZs/PT/Iw8rG7fVBDcQG/lOnEg=; b=d7vLOisV0LvXoHsyxxYWTS65COdeGEKrd27lFrp7Y/KmcX+6fVFT8Mk7/JutX+HfDt BzwIoxrcfAsTL/1n5/8RyR5JXwVFQqCWtmdVcICElg6yVXug+PEzSikJFKEpPRHIw8iz bIYJge5kt9+6kRJUs/sN2sSr0MlU4eJ/PJ9AmtgnWQoBUMoRt2mzXxC4JtTvFr5FrC/+ Ra4HL+PboQa0onXdaKDEo+ga6XhCZqdZHwC4GfY41eiszEVBPx7ny5XHOsHeYwlRQlU5 HkfMWWw1QEY+r94ssWfDw0O/o2y9JHQLr5r+i7ZlL7IcSltZ67bJYKOwH1wph3wPYA2v +DxQ== X-Gm-Message-State: AOAM533Zc+f8CZ32d9f8QWMpkQ1tMy2pZFpQZOBz0Bzmt5v6qtd10Z+b ujsyMhloJamppKPxSflj/+QtJUlDnbczbzFzjvc= X-Google-Smtp-Source: ABdhPJwr+Pi4t8Yh3UhO9QqRxdQUBl+grAhABzwg+QSQ6ZhzFhYd4qWSN4qUwV9uOFk1nVvYExy+qIBHYkexeZsiZes= X-Received: by 2002:ab0:2109:: with SMTP id d9mr10804725ual.76.1607325184157; Sun, 06 Dec 2020 23:13:04 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: "Murray S. Kucherawy" Date: Sun, 6 Dec 2020 23:12:50 -0800 Message-ID: To: John R Levine Cc: IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000a3edb605b5da8ea7" Archived-At: Subject: Re: [dmarc-ietf] Ticket #1 - SPF alignment X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 07 Dec 2020 07:13:07 -0000 --000000000000a3edb605b5da8ea7 Content-Type: text/plain; charset="UTF-8" On Tue, Dec 1, 2020 at 2:17 PM John R Levine wrote: > We would like to close this ticket by Dec 15, two weeks from now, so short > trenchant comments are welcome. > > Ticket #1 is about SPF alignment. We need to replace references to 4408 > with 7408, ando clarify what if anything we do with SPF HELO checks if > the MAIL FROM is null. One possibility is to say only MAIL FROM SPF > counts, if you want to align your bounces, sign them. The other is to > explicitly say that HELO alignment is OK on bounces. > I have a slight preference for the first option. HELO is too arbitrary in the protocol for me to put much value in using it in any of these systems. -MSK --000000000000a3edb605b5da8ea7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
We would like to close this ticket by Dec 15, two weeks from now= , so short
trenchant comments are welcome.

Ticket #1 is about SPF alignment.=C2=A0 We need to replace references to 44= 08
with 7408, ando clarify what if anything we do with SPF HELO checks if
the MAIL FROM is null.=C2=A0 One possibility is to say only MAIL FROM SPF <= br> counts, if you want to align your bounces, sign them.=C2=A0 The other is to=
explicitly say that HELO alignment is OK on bounces.
<= br>
I have a slight preference for the first option.=C2=A0 HELO i= s too arbitrary in the protocol for me to put much value in using it in any= of these systems.

-MSK
--000000000000a3edb605b5da8ea7-- From nobody Sun Dec 6 23:16: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 097163A10D8 for ; Sun, 6 Dec 2020 23:16:13 -0800 (PST) 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 BIaq8ClqLbeF for ; Sun, 6 Dec 2020 23:16:11 -0800 (PST) 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 1980B3A10DF for ; Sun, 6 Dec 2020 23:16:10 -0800 (PST) Received: by mail-vs1-xe2d.google.com with SMTP id x4so7005775vsp.7 for ; Sun, 06 Dec 2020 23:16:10 -0800 (PST) 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=kdZuZMh4I/QrUCTCR5Xb5Qwi+CWQpRTvCZufoqj+S5A=; b=NcLcy2ScRe+VVJZQ43ZLpZwUMgsn6JUbQquSeVxnd0L5NOyIRfKxBm4RICHVDzpqT1 duY9i/wiGLgjfxrb4hexP1Nc1sT2sqNnzybxGvuKuwG0fc7OwYppaZ5qX1K3aQMa0VqI fgbE4nMFbEFi9tcc/WH1BhKnDZEPby3p6eIp8d2LDOWvNlyZAV0KmtbaiN2IdB5A4nzc m6mn0sSNThDiMMzTJlvmLlW2T8ABOohyehKtkrtbWmJysmygrPnCBiDGqcTWlLctQP6U 0Cd4+nU46HsdoZ1snYpE/uzXlDTn4tWAexpR1cHmca0GDmMBcHo7rB/YKsyOwk4LPETv v1Sw== 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=kdZuZMh4I/QrUCTCR5Xb5Qwi+CWQpRTvCZufoqj+S5A=; b=iAf1gJC7deY+FEfcuI4DlCv/ISTyXTZW9SbLAp/e6SrVsNkQbcrvN7y8Jg3L+Aa3zR 9K/tgQjJa/XM79ts+33QlhjOSKzWvo+f7DKSP1S6OKguZ8gybJ3bB2ZFSQBeVrd9Rmtx krO03I2X0CDtPbEzzRZBgLRCirkQzPdBm1qMlhtSvSkkv1QJOJLmKW1pyZqvtZxJJArh 0l2z7TbROqznG/jEp+Y/grdA0UspA3jWD7OboJ7CSRqctOlvSYAoVwb0QXMyt7vUO3iQ a5VA3m7bFecja2huV10dhnfgtNZEUBZ9TicDLADorLEUz5h6bLzsPIs4q7SvPtxAwYP9 pjDQ== X-Gm-Message-State: AOAM531Ma/fq7JYIcBswzP07mf6qucGvosjOr3xFnP6HUtPInzpRPdzr OCbivj/TGX/JlFuntk0mjFFsljv4blYN0qQTuNAR64eR X-Google-Smtp-Source: ABdhPJx87D6Xi9aVMf27POjbAU8WW4S4UGByhZftNunKx+eEkxfhwMvDHLb+vNX9j+/qz+KClTy6sRbLfQ2zn9JdMvc= X-Received: by 2002:a67:1d07:: with SMTP id d7mr11174669vsd.33.1607325369980; Sun, 06 Dec 2020 23:16:09 -0800 (PST) MIME-Version: 1.0 References: <0408ae98-e1c1-71fe-fdd4-8bc7a7c151d3@tana.it> In-Reply-To: <0408ae98-e1c1-71fe-fdd4-8bc7a7c151d3@tana.it> From: "Murray S. Kucherawy" Date: Sun, 6 Dec 2020 23:15:57 -0800 Message-ID: To: Alessandro Vesely Cc: dmarc-ietf Content-Type: multipart/alternative; boundary="000000000000b75d9d05b5da9931" Archived-At: Subject: Re: [dmarc-ietf] Ticket #28 - Failure report mail loops X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2020 07:16:13 -0000 --000000000000b75d9d05b5da9931 Content-Type: text/plain; charset="UTF-8" On Fri, Dec 4, 2020 at 3:10 AM Alessandro Vesely wrote: > We would like to close this ticket by Dec 18, two weeks from now, so > please get > on it. > > The ticket originated from John's comment, in May 2019: > > Apropos recent discussions, we could recommend that failure reports be > rate limited per recipient both to break loops and to deter indirect > mail bombing. > > > The current draft discusses the topic toward the end of the introduction > of > Section 3, before the first subsection: > > An obvious consideration is the denial-of-service attack that can be > perpetrated by an attacker who sends numerous messages purporting to > be from the intended victim Domain Owner but that fail both SPF and > DKIM; this would cause participating Mail Receivers to send failure > reports to the Domain Owner or its delegate in potentially huge > volumes. Accordingly, participating Mail Receivers are encouraged to > aggregate these reports as much as is practical, using the Incidents > field of the Abuse Reporting Format ([RFC5965]). Various aggregation > techniques are possible, including the following: > > * only send a report to the first recipient of multi-recipient > messages; > > * store reports for a period of time before sending them, allowing > detection, collection, and reporting of like incidents; > > * apply rate limiting, such as a maximum number of reports per > minute that will be generated (and the remainder discarded). > > > Some issues the WG may want to consider: > > 1. That whole passage should be moved to its own subsection of Section 5, > "Security Considerations". Only a reference should be left in the intro. > Sure (though it's also fine where it is, IMHO). 2. In the first *-bullet above, the sense of multi-recipient is > ambiguous. An > explicit mention of ruf= might help. > I don't follow. 3. The 2nd and 3rd *-bullets may need expansion. Propose text in case. > Has anyone complained that they're too terse? 4. Some explicit loop prevention specification may be added. For example: > 4.1. send reports from a subdomain having a DMARC record without ruf=, or > 4.2. never send failure reports about failed reports. > The latter, which is consistent with SMTP never generating a bounce about a bounce. -MSK --000000000000b75d9d05b5da9931 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Fri, Dec 4, 2020 at 3:10 AM Alessandro= Vesely <vesely@tana.it> wrote:=
We would like to close this ticket by Dec 18, two weeks from no= w, so please get
on it.

The ticket originated from John's comment, in May 2019:

=C2=A0 =C2=A0 =C2=A0Apropos recent discussions, we could recommend that fai= lure reports be
=C2=A0 =C2=A0 =C2=A0rate limited per recipient both to break loops and to d= eter indirect
=C2=A0 =C2=A0 =C2=A0mail bombing.


The current draft discusses the topic toward the end of the introduction of=
Section 3, before the first subsection:

=C2=A0 =C2=A0 An obvious consideration is the denial-of-service attack that= can be
=C2=A0 =C2=A0 perpetrated by an attacker who sends numerous messages purpor= ting to
=C2=A0 =C2=A0 be from the intended victim Domain Owner but that fail both S= PF and
=C2=A0 =C2=A0 DKIM; this would cause participating Mail Receivers to send f= ailure
=C2=A0 =C2=A0 reports to the Domain Owner or its delegate in potentially hu= ge
=C2=A0 =C2=A0 volumes.=C2=A0 Accordingly, participating Mail Receivers are = encouraged to
=C2=A0 =C2=A0 aggregate these reports as much as is practical, using the In= cidents
=C2=A0 =C2=A0 field of the Abuse Reporting Format ([RFC5965]).=C2=A0 Variou= s aggregation
=C2=A0 =C2=A0 techniques are possible, including the following:

=C2=A0 =C2=A0 *=C2=A0 only send a report to the first recipient of multi-re= cipient
=C2=A0 =C2=A0 =C2=A0 =C2=A0messages;

=C2=A0 =C2=A0 *=C2=A0 store reports for a period of time before sending the= m, allowing
=C2=A0 =C2=A0 =C2=A0 =C2=A0detection, collection, and reporting of like inc= idents;

=C2=A0 =C2=A0 *=C2=A0 apply rate limiting, such as a maximum number of repo= rts per
=C2=A0 =C2=A0 =C2=A0 =C2=A0minute that will be generated (and the remainder= discarded).


Some issues the WG may want to consider:

1.=C2=A0 That whole passage should be moved to its own subsection of Sectio= n 5,
"Security Considerations".=C2=A0 Only a reference should be left = in the intro.

Sure (though it's als= o fine where it is, IMHO).

2.=C2=A0 In the first *-bullet above, the sense of multi-recipient is ambig= uous.=C2=A0 An
explicit mention of ruf=3D might help.

= I don't follow.

3.=C2=A0 The 2nd and 3rd *-bullets may need expansion.=C2=A0 Propose text i= n case.

Has anyone complained that they= 're too terse?

4.=C2=A0 Some explicit loop prevention specification may be added.=C2=A0 Fo= r example:
4.1.=C2=A0 send reports from a subdomain having a DMARC record without ruf= =3D, or
4.2.=C2=A0 never send failure reports about failed reports.

The latter, which is consistent with SMTP never genera= ting a bounce about a bounce.

-MSK
=
--000000000000b75d9d05b5da9931-- From nobody Sun Dec 6 23:18: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 7F9293A0D2F for ; Sun, 6 Dec 2020 23:18:37 -0800 (PST) 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 qWzA8dQWDzXO for ; Sun, 6 Dec 2020 23:18:36 -0800 (PST) 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 1F4F33A0CE4 for ; Sun, 6 Dec 2020 23:18:35 -0800 (PST) Received: by mail-ua1-x92f.google.com with SMTP id k12so4155635uae.13 for ; Sun, 06 Dec 2020 23:18:35 -0800 (PST) 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=JsVjWyjswBld1MEfRDJMnWjvj3r50uqBzkhOAyJ9Q4E=; b=FKHtCIm/F3KB//m+DKjWF9rhAj1KmvThkqrcm0tGH5lZV99elIZBdhgMUQjtJ8YrU1 UpGJ6HWz0DKEu50pQLeHCdCTZY7Vm8s+2Zp1qH6iJv30l8FxyMR98WDQaB9UTgeVkctu rsVLbgK1HySF7w5n7HCPgxO3KGfANYskhHCiICu/kuaFjMc49W7hpF+f/hZv2ffVF07z RJkp90ewVnwvOhkupOlxlKmEkbBQqYdpsJYxs4mdbM5a3WuYwJToyUXxNk8uEOvgsrye ca+2p3l3jj8VlcP5tbBWugfEYpZ9QLnW4Bzb9UsiQpRaUj9V9jBp05m0MFOA5QvKbmuW Bw1A== 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=JsVjWyjswBld1MEfRDJMnWjvj3r50uqBzkhOAyJ9Q4E=; b=OgMhE9IEC3OA75rVyX4kIJhrLqskxrqV8w5ZhMLdo/jQAwWbnq04zlOYPTQwdaTPDt zmVsmGxpYUUiVvckEwc0uhyd7Uja3dw2mVXr4nDMcFipAzNtQinEbtsbUi4PKwF95qzh pfQ5D1oBihyyOMsjlQR0MUrvygGbvfMDAHZhrhbSrEdj2YFve5HC2WaKm4V2HVyiOS77 OxRBfHI5d+uCcDz9xwEgtYnFRYGPPPdCe9h6eADwRwLsonU2zHga16+RgsRCmecJGaox ac3+08z5R4vK38+jyFnUTvok5haK1JO9kfvxQxatbr2H/ICHKzG6rIw5u+EEIG3BA4N3 EbVg== X-Gm-Message-State: AOAM531EhKYNNaMJ9SMonYmy4uej9JYyYb4TcfHcajpgPyY4iFfoYFyQ zv81YaqDex7GDqHYI5bSbPrwdZFvT2nvLg/D3BXv6RbY X-Google-Smtp-Source: ABdhPJwSEmRwDtGhGRPcEZlkC5q3zmqTTUBCcWQ7RhQGbWnOr0c1e6WUO/yU4p0joj1QC1HofMYXQ9DixBMSWiXdqFE= X-Received: by 2002:ab0:2e9:: with SMTP id 96mr10812621uah.87.1607325514886; Sun, 06 Dec 2020 23:18:34 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: "Murray S. Kucherawy" Date: Sun, 6 Dec 2020 23:18:22 -0800 Message-ID: To: John R Levine Cc: IETF DMARC WG Content-Type: multipart/alternative; boundary="0000000000005a798a05b5daa22c" Archived-At: Subject: Re: [dmarc-ietf] Ticket #42 - Expand DMARC reporting URI functionality X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 07 Dec 2020 07:18:38 -0000 --0000000000005a798a05b5daa22c Content-Type: text/plain; charset="UTF-8" On Tue, Dec 1, 2020 at 2:22 PM John R Levine wrote: > We would like to close this ticket by Dec 15, two weeks from now, so short > trenchant comments are welcome. > > Ticket #1 is about https reporting. Early drafts of the DMARC spec had a > poorly defined http report which we took out. I propose we add back https > reporting similar to that for mta-sts, with a POST of the gzipped report > to the HTTPS URI. > Was this requested by someone? -MSK --0000000000005a798a05b5daa22c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Dec 1, 2020 at 2:22 PM John R Lev= ine <johnl@taugh.com> wrote:
We would like to close this ticket by Dec 15, two weeks from now= , so short
trenchant comments are welcome.

Ticket #1 is about https reporting.=C2=A0 Early drafts of the DMARC spec ha= d a
poorly defined http report which we took out.=C2=A0 I propose we add back h= ttps
reporting similar to that for mta-sts, with a POST of the gzipped report to the HTTPS URI.

Was this requested by= someone?

-MSK
--0000000000005a798a05b5daa22c-- From nobody Mon Dec 7 01:35: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 37A333A1286 for ; Mon, 7 Dec 2020 01:35:32 -0800 (PST) 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 V515JKb8f79X for ; Mon, 7 Dec 2020 01:35:30 -0800 (PST) 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 C26033A1285 for ; Mon, 7 Dec 2020 01:35:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1607333726; bh=g3tLjsHCOfY6FOuSoZQdzlup7oRp1Z+aqlWVkyk4JnA=; l=1556; h=To:References:From:Date:In-Reply-To; b=AKZKE/68ujHZQG/kb+rl2lTjXpHtK+BAMoVMqFNxNG12QYholowZS6Py/lr8N+jJv H7gmyrFplE0tRsjo/9s/8hUDdI9AYFbYbTknxcHt/Ad1i/mGDAEVvtGNFrCEI7LloC /0nYNQ2MTT1pa4Aij1cW77zvFNuRL/GXY4r1mBxik4uelnYZeDHRQ6Vz+j1f1 Authentication-Results: tana.it; auth=pass (details omitted) Original-From: Alessandro Vesely 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.000000005FCDF75E.00003A98; Mon, 07 Dec 2020 10:35:26 +0100 To: dmarc@ietf.org References: <20201205231059.2BA23290EDCD@ary.qy> <7ae42764-176d-11a8-e084-b10b6f676944@mtcc.com> <8142f18c-ac79-1f94-97d1-2704f0b4ceb6@mtcc.com> <72d32b62-64fb-937a-dac5-6f4c5816f523@mtcc.com> <80558d32-2498-f9b3-313f-2211c1731e73@tana.it> From: Alessandro Vesely Message-ID: <5cbc09c5-a373-1991-9aef-4f4a796f683a@tana.it> Date: Mon, 7 Dec 2020 10:35:26 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] ARC vs reject X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 07 Dec 2020 09:35:32 -0000 On Sun 06/Dec/2020 19:47:24 +0100 Michael Thomas wrote: > On 12/6/20 10:31 AM, Alessandro Vesely wrote: >> On Sun 06/Dec/2020 18:01:04 +0100 Michael Thomas wrote: >>> >>> This actually highlights why my observation is correct. If the intermediary >>> showed how to reverse their changes perfectly to be able to validate the >>> original signature, it says nothing about whether those changes to be >>> delivered to the recipient are acceptable to the originating domain. for the >>> case of a bank sending me sensitive mail, the answer is that it is never ok. >>> for somebody working on internet standards working on ietf lists, the answer >>> is that it is fine. hence trying to get two states of the one "reject" is >>> insufficient. >> >> For MLM transformations, this choice can be done by tuning DKIM signatures. >> A bank can choose to sign Sender: field (or lack thereof), or any other >> fields that a MLM has to change, and possibly use simple canonicalization. >> In that conditions, transformation reversion won't work.  It isn't a distinct >> DMARC state, formally. Yet, tuning DKIM signatures allows to harden or weaken >> the given DMARC state. >> > It seems a lot simpler for the originating domain to just be explicit about how > they feel about transformations by intermediaries. It's not like another short > ascii string is going to break the bank. A stated policy is certainly more explicit about the intent. However, it is subject to receivers interpretation and I-dont-care syndrome. Best Ale -- From nobody Mon Dec 7 02:31: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 855FD3A12C2 for ; Mon, 7 Dec 2020 02:31:36 -0800 (PST) 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 h8Rgup6uxnGB for ; Mon, 7 Dec 2020 02:31:35 -0800 (PST) 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 1B04F3A12B8 for ; Mon, 7 Dec 2020 02:31:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1607337091; bh=BPwuRjP2JjfwIjTxGfjBlX1tSYn+/K34nLOI3zBxaDA=; l=1043; h=To:References:From:Date:In-Reply-To; b=Cduhr8pRNFP3ISVlYLenEtBkE2JiTa0dEU/47LaMz64lQSJ4ngmiYeMnvIuOJvcG9 BqhzYsSAKXeSOHeNsWQPbhLhL4nPE5tPtmDlMTX5iYE4AN+GiW/mXAsfPGGbVkwFYl JMZOKYbLgTZbmkFUhtlOSiWdkv/kPxx6PilYLCIOpiEmGvf5rrogCGhbqRtds Authentication-Results: tana.it; auth=pass (details omitted) Original-From: Alessandro Vesely 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.000000005FCE0483.0000412D; Mon, 07 Dec 2020 11:31:31 +0100 To: dmarc@ietf.org References: <20201205210351.DB78E2904420@ary.qy> <28759E60-3A00-4D25-9490-34495B96EE10@bluepopcorn.net> <9c23d850-4164-1320-1c25-40554c1f64b@taugh.com> From: Alessandro Vesely Message-ID: Date: Mon, 7 Dec 2020 11:31:31 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] ARC vs reject X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 07 Dec 2020 10:31:37 -0000 On Sun 06/Dec/2020 05:14:18 +0100 John R Levine wrote: > On Sat, 5 Dec 2020, Jim Fenton wrote: > >> ... If the recipient domain accepts modifications by zero-reputation >> intermediaries (because there are so many of them, after all) > > I wouldn't call that a reasonable implementation of ARC.  The set of hosts that > are likely to send you mail with interesting ARC chains is relatively small, > and I don't think it changes very fast. Trustworthiness has to account for the probability that a trusted host is hacked, even occasionally, so as to spew phishing. Reasonableness is a number in [0, 1]. In the presence of a chain, one must consider the joint probability that any intermediary is hacked. Anyone observed long ARC chains? > I'd certainly be interested in hearing how people plan to compile and maintain > their lists of ARC-worthy hosts. There should be a means of exchanging trustworthiness values, so as to build the transitivity required to compute the joint probabilities. Best Ale -- From nobody Mon Dec 7 02:44: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 BD51C3A0BBE for ; Mon, 7 Dec 2020 02:44:23 -0800 (PST) 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 LcJlZeOuaU3G for ; Mon, 7 Dec 2020 02:44:21 -0800 (PST) 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 9CF773A12EA for ; Mon, 7 Dec 2020 02:44:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1607337850; bh=X2FozRElWmf2q7VpgbZaDHTxOMT3KrXGdJw2UsX7A5w=; l=648; h=To:Cc:References:From:Date:In-Reply-To; b=BHtMXH0pRdgI825b83zXaMGvdZMLKEJNC5nwxY6idq40OhVLlZQAQqp+sEjRtcA9y c70wHktgO2t3g4Wvz1lpRTI0WjF8akgd2AvMTtApGB9aLvVx01N9fUy8T5NaVZuAoa NFzqWqw//Nf4joztW+gt1SJbhZvmfYH6+QIkyIbzy+8SFH6jN7+mXzJeqS9CT Authentication-Results: tana.it; auth=pass (details omitted) Original-From: Alessandro Vesely Original-Cc: IETF DMARC WG 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.000000005FCE077A.000042AE; Mon, 07 Dec 2020 11:44:10 +0100 To: "Murray S. Kucherawy" , Michael Thomas Cc: IETF DMARC WG References: <20201205210351.DB78E2904420@ary.qy> <28759E60-3A00-4D25-9490-34495B96EE10@bluepopcorn.net> <9c23d850-4164-1320-1c25-40554c1f64b@taugh.com> From: Alessandro Vesely Message-ID: Date: Mon, 7 Dec 2020 11:44:10 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] ARC vs reject X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 07 Dec 2020 10:44:24 -0000 On Mon 07/Dec/2020 06:05:29 +0100 Murray S. Kucherawy wrote: > > A counter-argument I've heard often to the idea of reversible transformations > is that it can become a spam vector, no different than the argument against > "l=". Compared with the use of "l=" tag (Section 8.2 of [RFC6376]), the fact that footers are written in plain text removes the main security objection about footer additions. Namely, footers cannot completely replace the original content in the end recipient's eyes by exploiting lax HTML parsing in the MUA. https://tools.ietf.org/html/draft-vesely-dmarc-mlm-transform-00#section-6 Best Ale -- From nobody Mon Dec 7 03:09:29 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71DDE3A0BBC for ; Mon, 7 Dec 2020 03:09:28 -0800 (PST) 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 cQRFkmekxV2T for ; Mon, 7 Dec 2020 03:09:27 -0800 (PST) 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 1A7223A0B6B for ; Mon, 7 Dec 2020 03:09:26 -0800 (PST) Received: by mail-qk1-x72a.google.com with SMTP id x25so12100658qkj.3 for ; Mon, 07 Dec 2020 03:09:26 -0800 (PST) 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=Q4X7ci3nO11AZDpO3aOrJLxSMsaVuPa7znfHNpEQJWE=; b=lD1dmG7gnp8K2+3+kkUoevcd3ngsCbXtRL+AFjFwLQgbxWlRAmXUHIgv34a2WKpO3K vu0pOPVVpTxxTZhHLMQ/q/bj6TNRl4EflFSg7eyiGHb3ckahWHBG4rtxaiEOuU5A1swc TMhOLCBsdPiJhnSmgc1GPqUZXrdMrtp8uBQ2ZUKQByICwvjDDcqeNd/AAWEZVrBV4zc1 qXmuxXnBETibrNNnX2k0gz6zFppKNvMvPLcva+ZnITnY/0iZ2OMT5SSa81CEW40GLbLX a8Y0p+fmZ4uLpS4p9AWDQkiGU77wa/BYv2JwO7c0wuyRa0xg3jU4MoWqGAJHF7DqPpbu SICg== 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=Q4X7ci3nO11AZDpO3aOrJLxSMsaVuPa7znfHNpEQJWE=; b=YIFLr6ZfLUgRTho5Tp5BxEeapaUm6XNCpNFx0fKI3caF0Mz+TclDROKn88Gd/1v9K0 9lu1Nbt3TG/rLj7bQO0+SEKYcNQ2UxFSQRgEb/nBAmm7u4d+0gQD8yUhP4HCi0Qh/ruM U8QBU4CrU0QqhqhXKs41kjxGfsNcAoUGAs01uIJODLbChjbQW8ttagez66fc2eNvlQD1 V8ljU6QO3QOVROnz3gi8FJlaqRWyuEXZk/BWW4b6I1VolzRdDlKldTrfMQxvD7Yj2yag UhK+jjbjyW8BmiceI/vrMe0BOMPOOpYRJYM5LsRcjnRsQ/9IfN69WTsQ+O57J30pEdcW 9+9w== X-Gm-Message-State: AOAM533avwiqLgzVETSdVbh5/BfCtttg2cOuVBdtWEVmO4M4gYejjB/i zEEeeRpUlKwH2WsJOjanw4rMcrf5JeCiZBnO/aw= X-Google-Smtp-Source: ABdhPJxOI1HmF7BQ7yIQpuMzEbwMvnKold2DCboVFiDk3FmXwqbPEr3T45BLPm9Haat1wMMRe29XzHJEO/0zYZ2iV34= X-Received: by 2002:a37:b342:: with SMTP id c63mr23878733qkf.146.1607339366049; Mon, 07 Dec 2020 03:09:26 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Dotzero Date: Mon, 7 Dec 2020 06:09:14 -0500 Message-ID: To: "Murray S. Kucherawy" Cc: John R Levine , IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000f26cc105b5dddb34" Archived-At: Subject: Re: [dmarc-ietf] Ticket #1 - SPF alignment X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 07 Dec 2020 11:09:29 -0000 --000000000000f26cc105b5dddb34 Content-Type: text/plain; charset="UTF-8" On Mon, Dec 7, 2020 at 2:13 AM Murray S. Kucherawy wrote: > On Tue, Dec 1, 2020 at 2:17 PM John R Levine wrote: > >> We would like to close this ticket by Dec 15, two weeks from now, so >> short >> trenchant comments are welcome. >> >> Ticket #1 is about SPF alignment. We need to replace references to 4408 >> with 7408, ando clarify what if anything we do with SPF HELO checks if >> the MAIL FROM is null. One possibility is to say only MAIL FROM SPF >> counts, if you want to align your bounces, sign them. The other is to >> explicitly say that HELO alignment is OK on bounces. >> > > I have a slight preference for the first option. HELO is too arbitrary in > the protocol for me to put much value in using it in any of these systems. > > -MSK > +1 Michael Hammer --000000000000f26cc105b5dddb34 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Dec 7, 2020 at 2:13 AM Murray= S. Kucherawy <superuser@gmail.co= m> wrote:
On Tue, Dec 1, 2020 at 2:17 PM John R Le= vine <johnl@taugh.c= om> wrote:
We would like to close this ticket by Dec 15, = two weeks from now, so short
trenchant comments are welcome.

Ticket #1 is about SPF alignment.=C2=A0 We need to replace references to 44= 08
with 7408, ando clarify what if anything we do with SPF HELO checks if
the MAIL FROM is null.=C2=A0 One possibility is to say only MAIL FROM SPF <= br> counts, if you want to align your bounces, sign them.=C2=A0 The other is to=
explicitly say that HELO alignment is OK on bounces.
<= br>
I have a slight preference for the first option.=C2=A0 HELO i= s too arbitrary in the protocol for me to put much value in using it in any= of these systems.

-MSK

+1

Michael Hammer
<= /div>
--000000000000f26cc105b5dddb34-- From nobody Mon Dec 7 03:13: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 077F63A1319 for ; Mon, 7 Dec 2020 03:13:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.12 X-Spam-Level: X-Spam-Status: No, score=-2.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, 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 r0k3MWuVeYLc for ; Mon, 7 Dec 2020 03:13:05 -0800 (PST) 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 304353A1318 for ; Mon, 7 Dec 2020 03:13:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1607339582; bh=q2NelWCpf/1d2jUC2Lb9oGILgH0MmbI8HNf25+DgVN4=; l=3270; h=To:Cc:References:From:Date:In-Reply-To; b=DLIiWfnx7k+y084I0juL3LwrkUN0A33svzEK6kE89a6HaB9aEXkU+1ZsaFreK+Uaq MrUW1+aacPvhyNrzHTERVVx7SclITAG5ijItOkureU58AyrVyhfx8z8xfpdN6ODL+F 4CcITNYCgzXxxJqnyntQVJCq28jsQcOse44DxgutUrI9JNZWd4jZiypwAabO0 Authentication-Results: tana.it; auth=pass (details omitted) Original-From: Alessandro Vesely Original-Cc: dmarc-ietf 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.000000005FCE0E3E.00004673; Mon, 07 Dec 2020 12:13:02 +0100 To: "Murray S. Kucherawy" Cc: dmarc-ietf References: <0408ae98-e1c1-71fe-fdd4-8bc7a7c151d3@tana.it> From: Alessandro Vesely Message-ID: Date: Mon, 7 Dec 2020 12:13:02 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Ticket #28 - Failure report mail loops X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2020 11:13:07 -0000 On Mon 07/Dec/2020 08:15:57 +0100 Murray S. Kucherawy wrote: > On Fri, Dec 4, 2020 at 3:10 AM Alessandro Vesely wrote: > >> We would like to close this ticket by Dec 18, two weeks from now, so >> please get >> on it. >> >> The ticket originated from John's comment, in May 2019: >> >> Apropos recent discussions, we could recommend that failure reports be >> rate limited per recipient both to break loops and to deter indirect >> mail bombing. >> >> >> The current draft discusses the topic toward the end of the introduction >> of Section 3, before the first subsection: >> >> An obvious consideration is the denial-of-service attack that can be >> perpetrated by an attacker who sends numerous messages purporting to >> be from the intended victim Domain Owner but that fail both SPF and >> DKIM; this would cause participating Mail Receivers to send failure >> reports to the Domain Owner or its delegate in potentially huge >> volumes. Accordingly, participating Mail Receivers are encouraged to >> aggregate these reports as much as is practical, using the Incidents >> field of the Abuse Reporting Format ([RFC5965]). Various aggregation >> techniques are possible, including the following: >> >> * only send a report to the first recipient of multi-recipient >> messages; >> >> * store reports for a period of time before sending them, allowing >> detection, collection, and reporting of like incidents; >> >> * apply rate limiting, such as a maximum number of reports per >> minute that will be generated (and the remainder discarded). >> >> >> Some issues the WG may want to consider: >> >> 1. That whole passage should be moved to its own subsection of Section 5, >> "Security Considerations". Only a reference should be left in the intro. >> > > Sure (though it's also fine where it is, IMHO). Thanks. >> 2. In the first *-bullet above, the sense of multi-recipient is >> ambiguous. An explicit mention of ruf= might help. > > I don't follow. The two paragraphs before the one I quoted are: The destination(s) and nature of the reports are defined by the "ruf" and "fo" tags as defined in Section 6.3. Where multiple URIs are selected to receive failure reports, the report generator MUST make an attempt to deliver to each of them. They make it clear the sense of "multi-recipient". However, diagonal readers may miss that point, especially if the quoted part is moved. They would attribute the usual meaning to the phrase "multi-recipient messages", which makes no sense. >> 3. The 2nd and 3rd *-bullets may need expansion. Propose text in case. > > Has anyone complained that they're too terse? > > 4. Some explicit loop prevention specification may be added. For example: >> 4.1. send reports from a subdomain having a DMARC record without ruf=, or >> 4.2. never send failure reports about failed reports. > > The latter, which is consistent with SMTP never generating a bounce about a > bounce. However, SMTP has an operational definition of bounce, MAIL FROM:<>. Should we take the same stance? That is, send failure reports with an empty bounce address and never send failure reports to bounces or failure reports? Best Ale -- From nobody Mon Dec 7 03:17: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 B4F7F3A131D for ; Mon, 7 Dec 2020 03:17:35 -0800 (PST) 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 FPxLCM_Vyd9U for ; Mon, 7 Dec 2020 03:17:34 -0800 (PST) Received: from mail-qt1-x82f.google.com (mail-qt1-x82f.google.com [IPv6:2607:f8b0:4864:20::82f]) (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 711BB3A131B for ; Mon, 7 Dec 2020 03:17:34 -0800 (PST) Received: by mail-qt1-x82f.google.com with SMTP id u21so9041947qtw.11 for ; Mon, 07 Dec 2020 03:17:34 -0800 (PST) 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=YFGVOr5y67oS4gDrtDFk14AS68ltQR0Z2GNPQ9sHvno=; b=LGptN4A3wOcE+iWacJxxO0MQt6IBliBE1kOfOFn52u11VYywmbYWGVVIHlJV6gx02W eF2dyiLzWEzzajEwQSeaQlh92MI6FXvGOL/zDM6zlBLTmGTjuhHeU+C6R/zaRhOxfxLT E2/gIZXvvHsEYZ0COe/aEp908u3hYWvWSl/xXuvJ6uCgmXiNShV6QrcpGl8MejZngZSI 0Jkse8bFYB8RCaTI56uANSv+Gcqi8hnQQ+E6wOJy2/2qRCHi34i2mD08WMu7TZa4S03L SWIwfiX62HpzBjadrWK+wNSxU8SQA0r7lCFHtsFURKumKpzbebFP56aItAiWEgQ+qrlt NgYw== 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=YFGVOr5y67oS4gDrtDFk14AS68ltQR0Z2GNPQ9sHvno=; b=jwlfKci8NbQ+AjwGiZveSsiLieXWjvBJeFhdJApfx11I9qq8Pf236rvILebJVsgAHM mH+VTs76Mm9auHTuQkSta0YeFol1htzeqiiKxU61Qc3yrBilXFtJwen4hqMmhsxWaEP+ qZ3d6bl5nQv8JPgrOE4LQD4a8+oQRwkIXvR1zJHdpSp+AUG47OiiCnUBRJ9HWI80gbZ+ mBPTG9vjSsL9sL93pXJIHitBZU8yjNPeRyCLfNOAhNX7pJQEHhdCNu/xWrbr8NeVJFWh XqZtBuk8H0d/t9SvF5GY4EBq9Fxa5CqotUpqshWxDsvAKcoTt0Y5X6lvrSIa2zRsUqkh AQWQ== X-Gm-Message-State: AOAM532Bv6fGnFqu4t5JbugEHior7VV92ki21sFmIAU0CV+TRFXUxxAN CihPqrU+pVxuM4L7e4STVxrlJaOIaQ7ypGo4CZs= X-Google-Smtp-Source: ABdhPJzfW5g0A3F4mF+kNVRxTmN/ca8Vd4Hfl4xJlF6YSmjm8nojhL6p9TuT0ovcWS5/Ki2pftlRFgj+ww3TqbQNCfU= X-Received: by 2002:ac8:5c05:: with SMTP id i5mr23330218qti.34.1607339850625; Mon, 07 Dec 2020 03:17:30 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Dotzero Date: Mon, 7 Dec 2020 06:17:19 -0500 Message-ID: To: "Murray S. Kucherawy" Cc: John R Levine , IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000d476d305b5ddf850" Archived-At: Subject: Re: [dmarc-ietf] Ticket #42 - Expand DMARC reporting URI functionality X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 07 Dec 2020 11:17:36 -0000 --000000000000d476d305b5ddf850 Content-Type: text/plain; charset="UTF-8" On Mon, Dec 7, 2020 at 2:18 AM Murray S. Kucherawy wrote: > On Tue, Dec 1, 2020 at 2:22 PM John R Levine wrote: > >> We would like to close this ticket by Dec 15, two weeks from now, so >> short >> trenchant comments are welcome. >> >> Ticket #1 is about https reporting. Early drafts of the DMARC spec had a >> poorly defined http report which we took out. I propose we add back >> https >> reporting similar to that for mta-sts, with a POST of the gzipped report >> to the HTTPS URI. >> > > Was this requested by someone? > I don't recall a strong security and privacy concerns discussion around HTTP(S) reporting. Presumably the report contents are protected in transit but to what extent is access by arbitrary parties an issue. Notwithstanding that things like GDPR are political issues, they are worth noting as a real life operational consideration. Michael Hammer --000000000000d476d305b5ddf850 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Dec 7, 2020 at 2:18 AM Murray= S. Kucherawy <superuser@gmail.co= m> wrote:
On Tue, Dec 1, 2020 at 2:22 PM John R Le= vine <johnl@taugh.c= om> wrote:
We would like to close this ticket by Dec 15, = two weeks from now, so short
trenchant comments are welcome.

Ticket #1 is about https reporting.=C2=A0 Early drafts of the DMARC spec ha= d a
poorly defined http report which we took out.=C2=A0 I propose we add back h= ttps
reporting similar to that for mta-sts, with a POST of the gzipped report to the HTTPS URI.

Was this requested by= someone?

I don't rec= all a strong security and privacy concerns discussion around HTTP(S) report= ing. Presumably the report contents are protected in transit but to what ex= tent is access by arbitrary parties an issue. Notwithstanding that things l= ike GDPR are political issues, they are worth noting as a real life operati= onal consideration.

Michael Hammer
=
--000000000000d476d305b5ddf850-- From nobody Mon Dec 7 03:41: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 CA4D03A1341 for ; Mon, 7 Dec 2020 03:41:14 -0800 (PST) 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 SakqZBGrjOHL for ; Mon, 7 Dec 2020 03:41:13 -0800 (PST) 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 135063A133E for ; Mon, 7 Dec 2020 03:41:12 -0800 (PST) Received: by mail-qt1-x829.google.com with SMTP id z9so9108564qtn.4 for ; Mon, 07 Dec 2020 03:41:12 -0800 (PST) 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=T808G1BZNG86EH9JcFkHLh0uyxQRYH9rd7/1JbKrdY8=; b=IfwbkzM0dIYpTAlciqBWU/32rQJBArqmYIpK4dqbmvytQim2M8AIxChNK5CoCz9Jv0 mR9mCeKbWKRxyfomSJN6W0xj1EkqCygpEnjDwzfWNWjM6gvigbWE19z+IrUxJtxKI+Rg xZaDEYgZnhJEAwKDmPc8pVG11j8q/wR1jW5Rg97uy/0NM3wqn1pAfe2OEUj2C9IS04UX ZmWIkJQiwy0B3G9+rno9Ra9OZI/QXwAA1bgI+vnu/Jl29C8JaOr9tlrux417mEnvme5y KjxqZx15CdH9B3ET5Y5WFQjv35353dTs2qunzecGar3QUXfE0B8ShSWqetVQF8gpSvYI Pu5A== 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=T808G1BZNG86EH9JcFkHLh0uyxQRYH9rd7/1JbKrdY8=; b=WEoqDsYPvL83JlWFE/xDph5gsACmCC8zApfDRmfz3jDL1NWVtbui7eAAUNB1RADP/G lirBA/ZrR0mQaCLGBzn82BNHeNcxoyDkWNK5UHr9x3CIu0HfZJbUe/tD62kM0VZwmAhr DnoWpvQoKRAol6u1UfD8S3jZe+Xou1gvXV3LKUKjV3AWnQ0CdNl+lRZYmjnzjSP78rgR BF58g0hkMLoA499dAFj1V0bWBCSsie2HipPSfRJzwpTkUcOfz5nbgp9r51j3qYe5xW7m fBaBe9KXj5tWC3IFJM8oUfiHiB5eVxqdP/1BbcIJZdKUcoh3RDOwViVujx7rpo//4VIL J0yA== X-Gm-Message-State: AOAM531d6q5pcMtT0QcA/XKCa1SNNkZN0wACcjZcOTCHCd+puaoq7tyk A+mQBnalPVBGnJwzGDPcdS55QZPszrWpl69RUSk= X-Google-Smtp-Source: ABdhPJx5lFmjLbFb5XzULjuNpyDs58xrpn+NyX0FrAOjT2IDZxZ9G641GtjDX/jOaMPDje96VlDBWEZGpKO1PjPKkxo= X-Received: by 2002:ac8:5c05:: with SMTP id i5mr23402826qti.34.1607341271843; Mon, 07 Dec 2020 03:41:11 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Dotzero Date: Mon, 7 Dec 2020 06:41:00 -0500 Message-ID: To: "Murray S. Kucherawy" Cc: Douglas Foster , IETF DMARC WG Content-Type: multipart/alternative; boundary="0000000000008a864b05b5de4d98" Archived-At: Subject: Re: [dmarc-ietf] DMARC and ARC X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 07 Dec 2020 11:41:15 -0000 --0000000000008a864b05b5de4d98 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Dec 7, 2020 at 12:15 AM Murray S. Kucherawy wrote: > On Fri, Dec 4, 2020 at 7:58 PM Douglas Foster < > dougfoster.emailstandards@gmail.com> wrote: > >> First, lets begin with the obvious: malicious messages come from >> enterprises that are in the malicious message business. They rarely se= nd >> just one message, and their content changes continually. Therefore, my >> priority is to block malicious sources. Messages that are correctly >> blocked on content, rather than source, are the canary-in-the-mine which >> warns me that my sender blocks need to be tightened. >> > > I was under the impression from my work in the anti-spam world that > sources also change. It's trivial to come from a new IP address or sign > with a new domain name when I think you're blocking me. Thus, negative > reputations are generally not useful to accumulate long term. On the > contrary, the thing that's mostly reliable is static sources that have go= od > reputations, because they tend to remain (mostly) static, and they work t= o > preserve their reputations. I tend to give them preferential treatment. > > If a message is not forwarded, every organization involved in its deliver= y >> is assumed to have a relationship to the sender and therefore a shared >> responsibility for the final product. DMARC, SPF, and many spam filter= s >> assume that the adjacent MTA is the only source that needs to be evaluat= ed. >> > This seems overly general. A message going from A to B to C to me here a= t > Gmail means Gmail has a relationship with A? > > Forwarding introduces an intermediary organization which presumably >> operates on behalf of the recipient, rather than the sender. It is not >> involved in the creation of the message and has no economic relationship >> with most of the message sources. More importantly, because it will be >> forwarding messages from sources with a variety of reputations, the >> forwarder will be perceived as having a very unreliable reputation =E2= =80=93 >> sending both very much unwanted content and very much wanted content fro= m >> the same or overlapping identifiers. SPF and DMARC force the forwarder= to >> reliably identify itself, but in this process, they force the forwarder = to >> hide information that the receiving MTA needs for proper message >> filtering. This aggravates any effort to filter based on original-sourc= e >> identity. >> > I'm also confused here, because it's ambiguous what you mean by > Forwarder. Some forwarders simply replace the envelope and send the > message on its way with no body modifications and only trace header field > changes. They don't meet the definition you're describing because no > details are hidden. Others, like MLMs, may mutate the message and re-pos= t > it, but I would argue that's not forwarding, that's a new message; the li= st > is the originator. > If there were truly a consensus on the list being the originator then the >From would/should be from the list domain and a lot of the list as intermediary issues would go away. As past discussions have shown, there is not such a consensus. Michael Hammer --0000000000008a864b05b5de4d98 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Dec 7, 2020 at 12:15 AM Murra= y S. Kucherawy <superuser@gmail.c= om> wrote:
On Fri, Dec 4, 2020 at 7:58 PM Douglas = Foster <dougfoster.emailstandards@gmail.com> wrote:
First, lets begin with the obvious:=C2=A0=C2=A0 malicious mess= ages come from enterprises that are in the malicious message business.=C2=A0=C2=A0 They rarely send just one message, and their content changes continually.= =C2=A0=C2=A0 Therefore, my priority is to block malicious sources.=C2=A0=C2=A0 Messages that are correctly blocked on content, rather than source, are the canary-in-the-mine which wa= rns me that my sender blocks need to be tightened.

I was under the impression from my w= ork in the anti-spam world that sources also change.=C2=A0 It's trivial= to come from a new IP address or sign with a new domain name when I think = you're blocking me.=C2=A0 Thus, negative reputations are generally not = useful to accumulate long term.=C2=A0 On the contrary, the thing that's= mostly reliable is static sources that have good reputations, because they= tend to remain (mostly) static, and they work to preserve their reputation= s.=C2=A0 I tend to give them preferential treatment.

If a message is not forwarded, every org= anization involved in its delivery is assumed to have a relationship to the sender and therefore = a shared responsibility for the final product.=C2=A0=C2=A0 DMARC, SPF, and many spam filters assume that the adjacent MTA is the only source that needs to be evaluated.

This seems overly general.=C2=A0 A message goin= g from A to B to C to me here at Gmail means Gmail has a relationship with = A?

Forwarding intr= oduces an intermediary organization which presumably operates on behalf of the recipient, rather than the sender.=C2=A0=C2=A0 It= is not involved in the creation of the message and has no economic relationship with most of the message sources.=C2=A0=C2=A0 More importantly, because it will be forwarding messages from sources with a variety of reput= ations, the forwarder will be perceived as having a very unreliable reputation =E2= =80=93 sending both very much unwanted content and very much wanted content from t= he same or overlapping identifiers.=C2=A0=C2=A0 SPF and DMARC force the forwarder to reliably identify itself, but in this process, they force the forwarder to hide information that the receiving MTA needs f= or proper message filtering.=C2=A0 This aggravates any effort to filter based = on original-source identity.

I'm also confus= ed here, because it's ambiguous what you mean by Forwarder.=C2=A0 Some = forwarders simply replace the envelope and send the message on its way with= no body modifications and only trace header field changes.=C2=A0 They don&= #39;t meet the definition you're describing because no details are hidd= en.=C2=A0 Others, like MLMs, may mutate the message and re-post it, but I w= ould argue that's not forwarding, that's a new message; the list is= the originator.

If t= here were truly a consensus on the list being the originator then the From = would/should be from the list domain and a lot of the list as intermediary = issues would go away. As past discussions have shown, there is not such a c= onsensus.

Michael Hammer
--0000000000008a864b05b5de4d98-- From nobody Mon Dec 7 04:05: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 46EEF3A0978 for ; Mon, 7 Dec 2020 04:05:43 -0800 (PST) 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 qdShlcX7eSYB for ; Mon, 7 Dec 2020 04:05:42 -0800 (PST) Received: from mail-qt1-x833.google.com (mail-qt1-x833.google.com [IPv6:2607:f8b0:4864:20::833]) (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 F1DD63A064B for ; Mon, 7 Dec 2020 04:05:41 -0800 (PST) Received: by mail-qt1-x833.google.com with SMTP id k4so9136629qtj.10 for ; Mon, 07 Dec 2020 04:05:41 -0800 (PST) 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=xs/Jz6a3XbTTjRCIm97Em4lm6sTladTcVXWPWtzOyPs=; b=ulR16E4+WqF7li7RhZnjWyPlRcow6xAfpe9LdyyiUROb0XqcIMWywa52c2sD92+vdx /3nDWX3KDPOqat/JCKven+NljYTCO25ULsEaM42aNl1ArOwa0hR/DNVl+3xjs+3WO9Y3 GHxwmMyEqM1lP3GYxrlPgpfGS05TrQdDn9oR7YCPE3jmtne2aIqCYCMWbsGebYJiXm4y 1spx6JaHGtFPqYJFbV+dPOFFiUFYjWBo1rO7nCL+3X2s7p5yi6VCaPidLk8e1fyKE0JP wucLJiGSo8BmyJkBhuyK2azHAW4pHZJ1D8KQDOYdB3v0DBOkUuJyIaq6qZAmxuG0a6e7 eYQw== 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=xs/Jz6a3XbTTjRCIm97Em4lm6sTladTcVXWPWtzOyPs=; b=rdRZ6YgABlLsTasiBufRQsktzLEN7GWphpPUF5A1vLit9iP4J1XK2lgtl9N8+Ggg+t 69tnWJGqELQAtvHuzAs2tRedj2Z/HBd3OOTW/1ffl9fbXuiIxPT0g5EmZXm69cMw6ZXd 3q3GJNeVbfsBup/7eBrv81Lgr7Fj+ljTi8w+9FtHbV7PQC67YcIr5bLM4DZ8MPJX3AVr PZzjvHZZAQh8kXpaSjToZ+w9lhgdybQDlu1polNgX+RgrU9ilppZvY7UeKooNF2Mpncl gHmJ/FbN9d29wk7yXa+vTvqsa5hpx494FtrVvM/qCoeVMj4QX151Qz0ry9MQRlN2p2DB 53lA== X-Gm-Message-State: AOAM533RNt7ztTESm6ciNp4Fck+K4dBIWOVNQHLsz3PmGo2tWGbvpVun S1Z7D73H/x8QAiksiDGt3Vwnwf6qmYA0wZ6vw60= X-Google-Smtp-Source: ABdhPJxo4QQKNR014TvOK/imCr/w1vMLT5/w71NsF1OpBgFdcXCNtysfFk8eUXFZIRqrQh05BL/9+iss0dVB9zupxBo= X-Received: by 2002:ac8:5412:: with SMTP id b18mr23428376qtq.220.1607342740767; Mon, 07 Dec 2020 04:05:40 -0800 (PST) MIME-Version: 1.0 References: <20201205210351.DB78E2904420@ary.qy> <28759E60-3A00-4D25-9490-34495B96EE10@bluepopcorn.net> <9c23d850-4164-1320-1c25-40554c1f64b@taugh.com> In-Reply-To: From: Dotzero Date: Mon, 7 Dec 2020 07:05:29 -0500 Message-ID: To: "Murray S. Kucherawy" Cc: Michael Thomas , IETF DMARC WG Content-Type: multipart/alternative; boundary="00000000000018889505b5dea5c0" Archived-At: Subject: Re: [dmarc-ietf] ARC vs reject X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 07 Dec 2020 12:05:43 -0000 --00000000000018889505b5dea5c0 Content-Type: text/plain; charset="UTF-8" On Mon, Dec 7, 2020 at 12:30 AM Murray S. Kucherawy wrote: > On Sun, Dec 6, 2020 at 9:24 PM Michael Thomas wrote: > >> An idea that i've been rolling around in my head is that the MLM could >> give a sed-like script to rollback the changes. since they know their >> modifications, they can obviously express how to unmodify them. it may have >> less issue with the mime hackery you were thinking about. >> > > You'd need a way to assert, and then evaluate, that something equivalent > to "s/.*/spam/g" is a transformation you're not willing to reverse and say > "yep, we're good." I don't know how you'd go about automating that. > >> But as far as your point about spam vectors it is surely just as true >> about ARC, right? at least with recovering the original text i have the >> ability to remove all of the transforms and deliver the original text. ARC >> not so much. it's all or nothing on the trust front. >> >> But I really think the key thing about all of this is figuring out what >> defines success. That is the most important thing by far. >> > I think ARC, like PSD, is meant to run for a while and see what we've > learned from it. Maybe it's the silver bullet, or maybe it's ineffective > complexity. That should be part of the experiment's definition; Section 11 > of the ARC RFC does try to capture all of that. > I've asked here and in other places that validators/receivers consuming ARC headers provide data regarding the results of such consumption. To date we have not seen any data provided by participants in the ARC experiment. It may be that ARC is a useful standard or it may not be. So far I'm seeing a lot of supposition and speculation but no useful data for evaluation. Michael Hammer --00000000000018889505b5dea5c0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Dec 7, 2020 at 12:30 AM Murra= y S. Kucherawy <superuser@gmail.c= om> wrote:
On Sun, Dec 6, 2020 at 9:24 PM Michael = Thomas <mike@mtcc.com= > wrote:
=20 =20 =20
An idea that i've been rolling around in my head is that the MLM could give a sed-like script to rollback the changes. since they know their modifications, they can obviously express how to unmodify them. it may have less issue with the mime hackery you were thinking about.

You= 9;d need a way to assert, and then evaluate, that something equivalent to &= quot;s/.*/spam/g" is a transformation you're not willing to revers= e and say "yep, we're good."=C2=A0 I don't know how you&#= 39;d go about automating that.
=20

But as far as your point about spam vectors it is surely just as true about ARC, right? at least with recovering the original text i have the ability to remove all of the transforms and deliver the original text.=C2=A0 ARC not so much. it's all or nothing on the = trust front.

But I really think the key thing about all of this is figuring out what defines success. That is the most important thing by far.

I think ARC, like PSD, is meant to run for a w= hile and see what we've learned from it.=C2=A0 Maybe it's the silve= r bullet, or maybe it's ineffective complexity.=C2=A0 That should be pa= rt of the experiment's definition; Section 11 of the ARC RFC does try t= o capture all of that.

I've asked here and in other places that validators/receivers consumi= ng ARC headers provide data regarding the results of such consumption. To d= ate we have not seen any data provided by participants in the ARC experimen= t. It may be that ARC is a useful standard or it may not be. So far I'm= seeing a lot of supposition and speculation but no useful data for evaluat= ion.

Michael Hammer
--00000000000018889505b5dea5c0-- From nobody Mon Dec 7 04:38: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 D6D313A1390 for ; Mon, 7 Dec 2020 04:38:11 -0800 (PST) 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 O_dSoYiP3Roy for ; Mon, 7 Dec 2020 04:38:09 -0800 (PST) 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 8E2FE3A1388 for ; Mon, 7 Dec 2020 04:38:09 -0800 (PST) Received: by mail-ua1-x932.google.com with SMTP id q68so4405718uaq.3 for ; Mon, 07 Dec 2020 04:38:09 -0800 (PST) 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=v7swuOi8+y6oULK/f4w/XEJUZPYVU2NuqST/Og5OGwI=; b=JQlm7AKRK9Qrw5VnPH6DV8A3YNx+m7tKYmEZ1l5z53I5SW0nPm8Ygbjr17ZY8DzepF Y9jQdQnjjEOG/LCL+Wshheh3Xi35+vooTOldRitTV97akRn9a2rW9IlRCtD7f4qlJwzs glCB19mCr8KL9rqbrK1g6PAzyYvhCNRe9rstobVaGMaLvZFFcTrjsJDJX/+ljKFBDoSq 4KMbHsL29BAzz5+pxokeNfnaYZh5tftAtZFrwVbNBB4RXYtR7ln4cMU5UOKMWpRn2+Nu OwPNu/4XvncE0gD64ZKBNQDdJd7O72QnqNpEU+yV0aRoOYFL7sujtokjijdy2xcpPSXF g6ng== 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=v7swuOi8+y6oULK/f4w/XEJUZPYVU2NuqST/Og5OGwI=; b=Mm6/fz1o93fC++yC43i4Bb2AWxwBTWXvy62Egi+sDXXQySC/Z3E++Ku2qm9qmaa616 Q31KLc+i97yduFgIwtc+ut0Z4hlsSJg4ebbm+Iv8X2na2GbSiI14yr+U9Pr2xE4GdCJD uYpTVP1GL3HfyxLHs5RUJuiwYWhL94kkE/LEYMILAawLANZ9h8ZSRzhJUj+Gb+oxhcHn 2g7JbxFa77qgv/SKdz09g48MYVKUcBc/WUK07Y6fkowejIGz/GwYxkoGflBTMw8F2bD5 ERcveVzlUdbsoe2UrdNr6V6TVHlrJ+2DOvOCVnvxSCgDBk92h6NDTj1Qme+Zga31CNmW 3Qtg== X-Gm-Message-State: AOAM530LEv31e5vtOaay+cAYreplwv2u+EsLJ8ghnw585P9FEh8q/Nv3 a6sE2q4L0A4Wuqm9/aqGLR3RsUA8WzSZMUsqr+E= X-Google-Smtp-Source: ABdhPJzRvONps5DcSAQbpuvw9++oyuC8+6Mysp4cpjO8JXR7NqsPzYah6w1udLy3jfxUrTm8DM1Xx8xcakPwnhjOdLg= X-Received: by 2002:ab0:2a4a:: with SMTP id p10mr11746036uar.95.1607344688302; Mon, 07 Dec 2020 04:38:08 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Douglas Foster Date: Mon, 7 Dec 2020 07:37:58 -0500 Message-ID: To: "Murray S. Kucherawy" Cc: IETF DMARC WG Content-Type: multipart/alternative; boundary="0000000000002d8f4105b5df19ff" Archived-At: Subject: Re: [dmarc-ietf] DMARC and ARC X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 07 Dec 2020 12:38:12 -0000 --0000000000002d8f4105b5df19ff Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks for engaging Murray. On the usefulness of source blacklisting: I have been using the model I described for about a year. I have two categories of mailers that account for nearly all of my spam: spamer-owned infrastructure which sends direct, and email service providers that accept all customers, including criminals. ESP messages will arrive SPF-aligned with the ESP domain, the From address indicates the client, and DKIM signing is used when necessary for DMARC compliance. I don't think I have seen any problems with infected servers or even infected accounts from trusted sources, which is surprising. Compliments to GMail that the worst that I get from them is unwanted-but-persistent advertising. Our employee base is measured in 4 digits, not 6, so our volume is smaller than many, and my desired-sender list is correspondingly small. That has meant that I have not had false positives with blacklisting. When a confirmed spam is received from spam infrastructure, the best defense is to blacklist the IP, the host domain, and the address domains (unless one of these has been spoofed.) In practice, this is tedious to do consistently. Blocking on server domain has proved pretty effective. When blocking on IP, we often block a subnet. Depending how quickly we identify the spam source, the message history sometimes provides a good outline of the boundaries of the spam infrastructure. Bottom line: spammer domains do change frequently, and spammers often have a bunch of servers. But their servers do not actually change very much. Obviously, this means I have not yet been attacked by a thousand-member bot-net. For spam received from ESPs, blocking on the From address works, because the ESP does verify the client identity and does not allow clients to spoof each other. They just don't vet client integrity. So I classify messages arriving from the ESP into known-bad=3Dblock, known-good=3Dallow, = and unknown=3Dquarantine. Forwarded messages will typically rewrite the SMTP domain for SPF compliance. This means that I no longer know that the unclassified From address is from the untrusted ESP and therefore needs to be quarantined. DMARC is a great solution for authorizing ESPs to send direct messages on behalf of a domain, because SPF did not work well for those messages. It is not a perfect solution for forwarded mail because even unmodified messages are subjected to data loss during forwarding. On Accountability: A message from A to B to C to Gmail does not mean that Gmail has a relationship with A. Gmail is acting as your agent, and it does a pretty good job of protecting you. A to B to C do have a relationship with each other, or one of them would have been bypassed. For legitimate senders, I expect that the organizational hops will be at most two: the source domain, and the outbound email filtering service used by the source domain. Mailing lists should be the cleanest traffic on the internet, because it should be a small matter for the list to verify sources and minimize risk by rejecting even slightly-doubtful messages. Yet we have had exchanges about how mailing list do not want to sign messages because they think it will make them accountable for what they forward. They are accountable for what they forward, with or without DKIM. Auto-forwarding operations are much more problematic because they have strong incentives to minimize false positives. They are still accountable, but they will be perceived by recipient as unreliable - the same way that I handle my problem ESPs. New vs Existing messages: For these purposes, mailing list output is only a new message if the mailing list is the only party responsible for its content. I am focused on identifying malicious and unwanted message sources, and the mailing list is asserting that it is not the originating source. DF -- On Mon, Dec 7, 2020 at 12:15 AM Murray S. Kucherawy wrote: > On Fri, Dec 4, 2020 at 7:58 PM Douglas Foster < > dougfoster.emailstandards@gmail.com> wrote: > >> First, lets begin with the obvious: malicious messages come from >> enterprises that are in the malicious message business. They rarely se= nd >> just one message, and their content changes continually. Therefore, my >> priority is to block malicious sources. Messages that are correctly >> blocked on content, rather than source, are the canary-in-the-mine which >> warns me that my sender blocks need to be tightened. >> > > I was under the impression from my work in the anti-spam world that > sources also change. It's trivial to come from a new IP address or sign > with a new domain name when I think you're blocking me. Thus, negative > reputations are generally not useful to accumulate long term. On the > contrary, the thing that's mostly reliable is static sources that have go= od > reputations, because they tend to remain (mostly) static, and they work t= o > preserve their reputations. I tend to give them preferential treatment. > > If a message is not forwarded, every organization involved in its deliver= y >> is assumed to have a relationship to the sender and therefore a shared >> responsibility for the final product. DMARC, SPF, and many spam filter= s >> assume that the adjacent MTA is the only source that needs to be evaluat= ed. >> > This seems overly general. A message going from A to B to C to me here a= t > Gmail means Gmail has a relationship with A? > > Forwarding introduces an intermediary organization which presumably >> operates on behalf of the recipient, rather than the sender. It is not >> involved in the creation of the message and has no economic relationship >> with most of the message sources. More importantly, because it will be >> forwarding messages from sources with a variety of reputations, the >> forwarder will be perceived as having a very unreliable reputation =E2= =80=93 >> sending both very much unwanted content and very much wanted content fro= m >> the same or overlapping identifiers. SPF and DMARC force the forwarder= to >> reliably identify itself, but in this process, they force the forwarder = to >> hide information that the receiving MTA needs for proper message >> filtering. This aggravates any effort to filter based on original-sourc= e >> identity. >> > I'm also confused here, because it's ambiguous what you mean by > Forwarder. Some forwarders simply replace the envelope and send the > message on its way with no body modifications and only trace header field > changes. They don't meet the definition you're describing because no > details are hidden. Others, like MLMs, may mutate the message and re-pos= t > it, but I would argue that's not forwarding, that's a new message; the li= st > is the originator. > > -MSK > --0000000000002d8f4105b5df19ff Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks for engaging Murray.

On the usef= ulness of source blacklisting:

I have been using t= he model I described for about a year.=C2=A0 =C2=A0 I have two categories o= f mailers that account for nearly all of my spam:=C2=A0 =C2=A0spamer-owned = infrastructure which sends direct, and email service providers that accept = all customers, including=C2=A0criminals.=C2=A0 =C2=A0ESP messages will arri= ve SPF-aligned with the ESP domain, the From address indicates the client, = and DKIM signing is used when necessary for DMARC compliance.
I don't think I have seen any problems with infected server= s or even infected accounts from trusted sources, which is surprising.=C2= =A0 =C2=A0Compliments to GMail that the worst that I get from them is unwan= ted-but-persistent advertising.

Our employee base = is measured in 4 digits, not 6, so our volume is smaller than many,=C2=A0an= d my desired-sender list is correspondingly small.=C2=A0 =C2=A0That has mea= nt that I have not had false positives with blacklisting.

When a confirmed=C2=A0spam is received from spam infrastructure, th= e best defense is to blacklist the IP, the host domain, and the address dom= ains (unless one of these has been spoofed.)=C2=A0 =C2=A0 In practice, this= is tedious to do consistently.=C2=A0 =C2=A0Blocking on server domain has p= roved pretty effective.=C2=A0 =C2=A0When blocking on IP, we often block a s= ubnet.=C2=A0 =C2=A0Depending how quickly we identify the spam source, the m= essage history sometimes provides a good outline of the boundaries of the s= pam infrastructure.=C2=A0 =C2=A0Bottom line:=C2=A0 =C2=A0spammer domains do= change frequently, and spammers often have a bunch of servers.=C2=A0 But t= heir servers do not actually=C2=A0change very much.=C2=A0 =C2=A0Obviously, = this means I have not yet been attacked by a thousand-member bot-net.
=

For spam received from ESPs, blocking on the From addre= ss works, because the ESP does verify the client identity and does not allo= w clients to spoof each other.=C2=A0 =C2=A0They just don't vet client i= ntegrity.=C2=A0 =C2=A0 So I classify messages arriving from the ESP into kn= own-bad=3Dblock, known-good=3Dallow, and unknown=3Dquarantine.=C2=A0 =C2=A0= Forwarded messages will typically=C2=A0rewrite the SMTP domain for SPF comp= liance.=C2=A0 =C2=A0This means that I no longer know that the unclassified = >From address is from the untrusted ESP and therefore needs to be quarantine= d.=C2=A0 =C2=A0 DMARC is a great solution for authorizing ESPs to send dire= ct messages on behalf of a domain, because SPF did not work well for those = messages.=C2=A0 =C2=A0It is not a perfect solution for forwarded mail becau= se even unmodified messages are subjected to data loss during forwarding.

On Accountability:

A messa= ge from A to B to C to Gmail does not mean that Gmail has a relationship wi= th A.=C2=A0 =C2=A0 Gmail is acting as your agent, and it does a pretty good= job of protecting you.=C2=A0 =C2=A0 A to B to C do have a relationship wit= h each other, or one of them would have been bypassed.=C2=A0 =C2=A0 For leg= itimate senders, I expect that the organizational=C2=A0hops will be at most= two:=C2=A0 =C2=A0 the source domain, and the outbound email filtering serv= ice used by the source domain.

Mailing lists shoul= d be the cleanest traffic on the internet, because it should be a small mat= ter for the list to verify sources and minimize risk by rejecting even slig= htly-doubtful messages.=C2=A0 =C2=A0 Yet we have had exchanges about how ma= iling list do not want to=C2=A0sign messages because they think it=C2=A0wil= l=C2=A0make them accountable for what they=C2=A0forward.=C2=A0 =C2=A0They a= re accountable for what they forward, with or without DKIM.

<= /div>
Auto-forwarding operations are much more problematic because they= have strong incentives to minimize false positives.=C2=A0 =C2=A0They are s= till accountable, but they will be perceived by recipient as unreliable - t= he same way that I handle my problem ESPs.

New vs = Existing messages:

For these purposes, mailing lis= t output is only a new message if the mailing list is the only party respon= sible for its content.=C2=A0 I am focused on identifying malicious and unwa= nted message=C2=A0sources, and the=C2=A0mailing list is asserting that it i= s not the originating source.

DF

--


On Mon, Dec 7, 2020 at 12:15 AM Murray S. Ku= cherawy <superuser@gmail.com&= gt; wrote:
On Fri, Dec 4, 2020 at 7:58 PM Douglas Foster = <dougfoster.emailstandards@gmail.com> wrote:
First, lets begin with the obvious:=C2=A0=C2=A0 malicious messages co= me from enterprises that are in the malicious message business.=C2=A0=C2=A0 They rarely send just one message, and their content changes continually.= =C2=A0=C2=A0 Therefore, my priority is to block malicious sources.=C2=A0=C2=A0 Messages that are correctly blocked on content, rather than source, are the canary-in-the-mine which wa= rns me that my sender blocks need to be tightened.

I was under the impression from my w= ork in the anti-spam world that sources also change.=C2=A0 It's trivial= to come from a new IP address or sign with a new domain name when I think = you're blocking me.=C2=A0 Thus, negative reputations are generally not = useful to accumulate long term.=C2=A0 On the contrary, the thing that's= mostly reliable is static sources that have good reputations, because they= tend to remain (mostly) static, and they work to preserve their reputation= s.=C2=A0 I tend to give them preferential treatment.

If a message is not forwarded, every org= anization involved in its delivery is assumed to have a relationship to the sender and therefore = a shared responsibility for the final product.=C2=A0=C2=A0 DMARC, SPF, and many spam filters assume that the adjacent MTA is the only source that needs to be evaluated.

This seems overly general.=C2=A0 A message goin= g from A to B to C to me here at Gmail means Gmail has a relationship with = A?

Forwarding intr= oduces an intermediary organization which presumably operates on behalf of the recipient, rather than the sender.=C2=A0=C2=A0 It= is not involved in the creation of the message and has no economic relationship with most of the message sources.=C2=A0=C2=A0 More importantly, because it will be forwarding messages from sources with a variety of reput= ations, the forwarder will be perceived as having a very unreliable reputation =E2= =80=93 sending both very much unwanted content and very much wanted content from t= he same or overlapping identifiers.=C2=A0=C2=A0 SPF and DMARC force the forwarder to reliably identify itself, but in this process, they force the forwarder to hide information that the receiving MTA needs f= or proper message filtering.=C2=A0 This aggravates any effort to filter based = on original-source identity.

I'm also confus= ed here, because it's ambiguous what you mean by Forwarder.=C2=A0 Some = forwarders simply replace the envelope and send the message on its way with= no body modifications and only trace header field changes.=C2=A0 They don&= #39;t meet the definition you're describing because no details are hidd= en.=C2=A0 Others, like MLMs, may mutate the message and re-post it, but I w= ould argue that's not forwarding, that's a new message; the list is= the originator.

-MSK
--0000000000002d8f4105b5df19ff-- From nobody Mon Dec 7 08:46: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 CB93E3A12E7 for ; Mon, 7 Dec 2020 08:46:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.652 X-Spam-Level: X-Spam-Status: No, score=-1.652 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mtcc-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k-FcYJKqi47C for ; Mon, 7 Dec 2020 08:46:54 -0800 (PST) Received: from mail-pj1-x102f.google.com (mail-pj1-x102f.google.com [IPv6:2607:f8b0:4864:20::102f]) (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 B7B2C3A0FC2 for ; Mon, 7 Dec 2020 08:46:54 -0800 (PST) Received: by mail-pj1-x102f.google.com with SMTP id o7so7779269pjj.2 for ; Mon, 07 Dec 2020 08:46:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mtcc-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=t9LDQy+6kr+aUo7GRNrGwi/7ZIQKqLm6Znds3UFAT1I=; b=Y/gN9wXrfMrXNoSQ26jq4dHEopZ1i7IkMk4NvlOvqyKTrkyaB/zvtHAEOe/NcZrPfD jjx/lOwBl8PVCKkMJDEyWEK5eqcIM/c3KWLitCUmmFr3o1vMbDUS1JG5gkqDCx8+Yq86 DcjAdBWskIYFIKLA1rvO0sW9Covg3CgVFpGaoQyxS+RXjgGjFfEiI1MnLaWkQegYL7Tp 4DlbQKQHU3QM3bEkJPRbQdNUsZZea2U8KMBFzdCDsi1UiOjkOGnn6+jv+rKNOn7y9DaS sW69LNAJSo6eku378ml0b8tG/A+bUPG6rxEvd3sJyCpFxstuQirFCPHquXC8N7odVsoP Ds7g== 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=t9LDQy+6kr+aUo7GRNrGwi/7ZIQKqLm6Znds3UFAT1I=; b=lf/Vy7S3hiCRdYXZj5e1ZYQZvBT5cSLQ7YJvG+y/RJziZjUeItTn/B0t8g/4tk0oDh VY838jZLgWnfLwWE0OuCr0JlIed2qB/o9jV3JBHDw3G45y2aODongw9PCXeopDk/Eqbb Z/j0SldF/nQiXB5R7zbNXLhtW6WsbZbZEYIZe0z29cA4wWX905zBbNtd/vWqe+7IL8Km fyYWMKdDUfSHLSng8js/xujqFENFP6nx9BEK2RffKERrfYCR3Rh5PhQrOSxDmtBSicbb CHIj7dptWIwAIKdbwVCeh9hivY9v9XAfom0MrFrPDdt9fh/UETGaNawjx4m7KV2hqUJe QolA== X-Gm-Message-State: AOAM531MtWzMGKTLM86jPqjrZe13J0bHAOFOu0s8NOGY5sVFkDcWM+NL ed+izCEWNXz56ut3qVsspZs8Gn7na4gWAQ== X-Google-Smtp-Source: ABdhPJyPyjhXUO2TBT8v3GHRGzBzJIm8EgL3a8fzOv7DdSvVp2er7kHgRndzEEp6IAzFRtCo3XN49Q== X-Received: by 2002:a17:90a:ee8c:: with SMTP id i12mr17428505pjz.33.1607359613639; Mon, 07 Dec 2020 08:46:53 -0800 (PST) Received: from mike-mac.lan (107-182-41-154.volcanocom.com. [107.182.41.154]) by smtp.gmail.com with ESMTPSA id i4sm12995695pgg.67.2020.12.07.08.46.52 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 07 Dec 2020 08:46:52 -0800 (PST) To: dmarc@ietf.org References: <20201205231059.2BA23290EDCD@ary.qy> <7ae42764-176d-11a8-e084-b10b6f676944@mtcc.com> <8142f18c-ac79-1f94-97d1-2704f0b4ceb6@mtcc.com> <72d32b62-64fb-937a-dac5-6f4c5816f523@mtcc.com> <80558d32-2498-f9b3-313f-2211c1731e73@tana.it> <5cbc09c5-a373-1991-9aef-4f4a796f683a@tana.it> From: Michael Thomas Message-ID: Date: Mon, 7 Dec 2020 08:46:51 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 MIME-Version: 1.0 In-Reply-To: <5cbc09c5-a373-1991-9aef-4f4a796f683a@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] ARC vs reject X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 07 Dec 2020 16:46:56 -0000 On 12/7/20 1:35 AM, Alessandro Vesely wrote: > On Sun 06/Dec/2020 19:47:24 +0100 Michael Thomas wrote: >> It seems a lot simpler for the originating domain to just be explicit >> about how they feel about transformations by intermediaries. It's not >> like another short ascii string is going to break the bank. > > > A stated policy is certainly more explicit about the intent. However, > it is subject to receivers interpretation and I-dont-care syndrome. > > Yes, the best the sending domain can ever do is state their wishes. But they should be able to state their wishes concisely. We're only talking about code points here. As a standards organization, we shouldn't be hung up about whether people will care. That is extremely defeatist and begs the question of why bother doing anything. Mike From nobody Mon Dec 7 08:49: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 5D3B33A15BE for ; Mon, 7 Dec 2020 08:49:18 -0800 (PST) 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 (2048-bit key) header.d=iecc.com header.b=ZXUWwaB9; dkim=pass (2048-bit key) header.d=taugh.com header.b=mFZJC4uE Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a4exyF3YJDl4 for ; Mon, 7 Dec 2020 08:49:16 -0800 (PST) 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 F29F73A12E7 for ; Mon, 7 Dec 2020 08:49:15 -0800 (PST) Received: (qmail 49134 invoked from network); 7 Dec 2020 16:49:10 -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=bfec.5fce5d06.k2012; i=johnl-iecc.com@submit.iecc.com; bh=deJ2q432PefvW84XgxaKDw6k/BXBnJH0sWXVJNpmexQ=; b=ZXUWwaB9TQ/IiVoaidXoOCB/fL1zG5awM9nAg61wItCLbY4lVyfABKXYjnryHqRcuhrGx5PJ2fzPokiM1E0qo7YBQYZyZULO4VmN9q+Zyc3dAneyIfPJl3lgIVZUmF4/oFd2RRnrddgSYkgxoIC/QRIRUqUn1hA8s+kAu8Qbn6oy0hG/78KUjVwQO8XgiQMZ+CjVVXvv6Hs5jOqtOjZYE+05v5GgELVU4FLMOJ16PhVVIB8fLwvfGUXIEbPYWAVaRyY5PFRw19WLi5s1eBw2vT7x/S3nrGcV4FzLQNVxXWcTFoOc1ICYk++GDMLeTzBuk0VLFVV8OseueZWeUMZeTw== 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=bfec.5fce5d06.k2012; olt=johnl-iecc.com@submit.iecc.com; bh=deJ2q432PefvW84XgxaKDw6k/BXBnJH0sWXVJNpmexQ=; b=mFZJC4uEW9y1EhUtdlA9/5FbC1s2Ci6Yr+mduaWb7A2Rh9rKuGLU4j8c/87DJgfdQD3zkGCYXo+2KdogWykbpRQqgus/ZNmBUGVs+HZFptJJEV0s/6UhjTcoKXTvL+XIa6nG8WmY6Md2JPVxYrcB9cPuLSF2wrAfd2aaMY3ynppqVgih5M8OKtFddT/nMgnRjrmjNGKFtGsiIey5voiKwcdyZ2ndkw6W4vttl++ug7Ai15xQ0WHH/Q/zG1yrERZe+veOuFBf/v4xgnkiMqFHtf3AU64eJLG9mJ0NKyrZbwLXJqHLM39GuEa9M5CqokhHnmcn7DJC3abL3pG5qsXG5A== 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 Dec 2020 16:49:10 -0000 Date: 7 Dec 2020 11:49:09 -0500 Message-ID: From: "John R Levine" To: "Dotzero" , "Murray S. Kucherawy" Cc: "IETF DMARC WG" In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [dmarc-ietf] Ticket #42 - Expand DMARC reporting URI functionality X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 07 Dec 2020 16:49:20 -0000 >>> poorly defined http report which we took out. I propose we add back >>> https reporting similar to that for mta-sts, with a POST of the gzipped report >>> to the HTTPS URI. >> >> Was this requested by someone? > > I don't recall a strong security and privacy concerns discussion around > HTTP(S) reporting. Presumably the report contents are protected in transit > but to what extent is access by arbitrary parties an issue. Notwithstanding > that things like GDPR are political issues, they are worth noting as a real > life operational consideration. The original motivation was performance, since uploading a big file via https is a lot faster than base64 encoding it and relaying it by mail. I don't understand the security or GDPR references. For one thing, these are aggregate reports which generally don't have any PII. For another, https reporting would be considerably more secure than mail reporting. The report goes via an encrypted channel directly to the target server which is identified by its ssl certificate. There's no relaying through intermediate servers. If the report can't be delivered, the upload just fails and there's no possibility of it being diverted by spam filters or bouncing into some random admin mailbox. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From nobody Mon Dec 7 08: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 458933A146B for ; Mon, 7 Dec 2020 08:59:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.65 X-Spam-Level: X-Spam-Status: No, score=-1.65 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, 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=mtcc-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eLBgsqCYfBpB for ; Mon, 7 Dec 2020 08:59:49 -0800 (PST) Received: from mail-pj1-x102e.google.com (mail-pj1-x102e.google.com [IPv6:2607:f8b0:4864:20::102e]) (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 EF3B83A12E7 for ; Mon, 7 Dec 2020 08:59:48 -0800 (PST) Received: by mail-pj1-x102e.google.com with SMTP id e5so7692001pjt.0 for ; Mon, 07 Dec 2020 08:59:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mtcc-com.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=CN9IJ1xOpMU6r6rCdj2a/bMXyyMG4LUECK99f+Kzx+A=; b=ivxo+5mC40CPBYwTrga0tKAx2GSCwbLlUali8H2E6uzP0uQXrD3qHZpNKroP5qb3oD dgkGpR9u2UbZnJsbguXtQRkrKF4fVr7PQlwTl36v/bUpcovKrbtVM7YUFOcsRh4P+Xth ohmtE0JLjF1w4hL2Mnl+x390kTMpG2IE1Zt0POGnUFHqs/KoZrYLXqsDlgQSrtg6K3Hc 7oLP0hRBO6NiW08VMb3Eix8e7RA0XI0UF8fWmwz7g+niI0KLMDRpJIT5usCq0LpwQ3SR NCQnvYBE3A6UvrnlFYfkhuNRx4XMkR4rFRsINmwuxgLMojddo/RxUCIehHl0jdmmdbEk Pggw== 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=CN9IJ1xOpMU6r6rCdj2a/bMXyyMG4LUECK99f+Kzx+A=; b=o6QzVwbvtiYHDWAZSor+7//axAlQvu5v8u3y7m8BdPAauE5Zj4n+wP7jiWGMgUn20c 984qHTfPTaVaXofuaLk3ZzsECxZxOGAQEuvkbGu1P9c95WpxMEmsyD5zTE7ki7gIFOw3 dGYuLM+ILIP93edIAyM9a4vePQUhkkFMANPZ+vQguMS+Iap6ovvQE2m0/zKIiugtzkr3 /e6K0K1tjQ2p5ygABmQF9ECBqUKhHFWbCMhAhw5a0vApfJX8D67Vlvq/ASEoh1pR8Ko0 a/iLEqlcDr5dHySF6EJOkqjxtz5eDR916Xg0r5E1zYuNAZcji0tlLQ0HdopMzodvX1Bi oiog== X-Gm-Message-State: AOAM530EKb0VqixUTENpOhEqY2dCpH+TLMWbLGYHR6WaRO3C4AMmyy1w iPCpKTx9fJgfxVanqExHf5CLcfE99vWHaA== X-Google-Smtp-Source: ABdhPJxqrb416dBPi+vR6MvQKYlOlAd/lnYclA5PZiRdoV+r3Qln2O6YAT3id0v4BnURx5RHcLozMA== X-Received: by 2002:a17:90a:c6:: with SMTP id v6mr16967019pjd.95.1607360388084; Mon, 07 Dec 2020 08:59:48 -0800 (PST) Received: from mike-mac.lan (107-182-41-154.volcanocom.com. [107.182.41.154]) by smtp.gmail.com with ESMTPSA id fs12sm11041663pjb.49.2020.12.07.08.59.46 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 07 Dec 2020 08:59:47 -0800 (PST) To: "Murray S. Kucherawy" Cc: IETF DMARC WG References: <20201205210351.DB78E2904420@ary.qy> <28759E60-3A00-4D25-9490-34495B96EE10@bluepopcorn.net> <9c23d850-4164-1320-1c25-40554c1f64b@taugh.com> From: Michael Thomas Message-ID: <83dc465e-b857-b22b-b2f2-2d7ba4d74955@mtcc.com> Date: Mon, 7 Dec 2020 08:59:45 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------03783D54847D2CFDE52FD844" Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] ARC vs reject X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 07 Dec 2020 16:59:50 -0000 This is a multi-part message in MIME format. --------------03783D54847D2CFDE52FD844 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 12/6/20 9:30 PM, Murray S. Kucherawy wrote: > On Sun, Dec 6, 2020 at 9:24 PM Michael Thomas > wrote: > > An idea that i've been rolling around in my head is that the MLM > could give a sed-like script to rollback the changes. since they > know their modifications, they can obviously express how to > unmodify them. it may have less issue with the mime hackery you > were thinking about. > > > You'd need a way to assert, and then evaluate, that something > equivalent to "s/.*/spam/g" is a transformation you're not willing to > reverse and say "yep, we're good."  I don't know how you'd go about > automating that. > > But as far as your point about spam vectors it is surely just as > true about ARC, right? at least with recovering the original text > i have the ability to remove all of the transforms and deliver the > original text.  ARC not so much. it's all or nothing on the trust > front. > > But I really think the key thing about all of this is figuring out > what defines success. That is the most important thing by far. > > I think ARC, like PSD, is meant to run for a while and see what we've > learned from it.  Maybe it's the silver bullet, or maybe it's > ineffective complexity.  That should be part of the experiment's > definition; Section 11 of the ARC RFC does try to capture all of that. > Btw, what is PSD? Mike --------------03783D54847D2CFDE52FD844 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit


On 12/6/20 9:30 PM, Murray S. Kucherawy wrote:
On Sun, Dec 6, 2020 at 9:24 PM Michael Thomas <mike@mtcc.com> wrote:
An idea that i've been rolling around in my head is that the MLM could give a sed-like script to rollback the changes. since they know their modifications, they can obviously express how to unmodify them. it may have less issue with the mime hackery you were thinking about.

You'd need a way to assert, and then evaluate, that something equivalent to "s/.*/spam/g" is a transformation you're not willing to reverse and say "yep, we're good."  I don't know how you'd go about automating that.

But as far as your point about spam vectors it is surely just as true about ARC, right? at least with recovering the original text i have the ability to remove all of the transforms and deliver the original text.  ARC not so much. it's all or nothing on the trust front.

But I really think the key thing about all of this is figuring out what defines success. That is the most important thing by far.

I think ARC, like PSD, is meant to run for a while and see what we've learned from it.  Maybe it's the silver bullet, or maybe it's ineffective complexity.  That should be part of the experiment's definition; Section 11 of the ARC RFC does try to capture all of that.

Btw, what is PSD?

Mike

--------------03783D54847D2CFDE52FD844-- From nobody Mon Dec 7 10:32: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 0F7A43A07C8 for ; Mon, 7 Dec 2020 10:32:39 -0800 (PST) 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 QGcp5dRxhCG3 for ; Mon, 7 Dec 2020 10:32:37 -0800 (PST) Received: from mail-vk1-xa2c.google.com (mail-vk1-xa2c.google.com [IPv6:2607:f8b0:4864:20::a2c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8AB643A033F for ; Mon, 7 Dec 2020 10:32:35 -0800 (PST) Received: by mail-vk1-xa2c.google.com with SMTP id i62so3325981vkb.7 for ; Mon, 07 Dec 2020 10:32:35 -0800 (PST) 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=Lp0xRLkQ6P9XjddYIRgMo2hiBJgTWRJQFZrbxX6u3Fo=; b=s+E8L1FzUNCN1vF+x6llyfi+LckvpmQuEnn80/UQpL0eM4cXwg2Rf/ELIyxJepuRiO VMqJ/eqK+lFAZHqpYB5JxAln5di2mFOALpnZGXmpWD0/gdAzirTWyH8jxcbWAJZ8D0aN lbJSRjhpaUIZtB2EhMOo3YJ5SjSN4bIrNfPWBPCxkQ5Mz7rumjHlGVxoL1y2o9ieCHfk 3WimK82rp94SiKMOqPrDM1PFaaPFCvjY94BU5YPaszaC3N8rVVulBwN99+bFAWrkATW4 GqPk6dbb7uR03l2cG2nk16wYZs3DcSrpufbS+eNfmUFjmVzIKAHjMCYpIXxUXqYPvUv6 ilog== 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=Lp0xRLkQ6P9XjddYIRgMo2hiBJgTWRJQFZrbxX6u3Fo=; b=gWeqxO+3FzrQHSLVwaMXvtxd8P0eD/eNFCRvzLKwqvhO3g9aZT29kOH+nmdmJkqfdR P5+h37aPJyAIfug1pGYo8OXoKDZ2U4RXCxlEJfbtlCTSJWSABXBEuUxINrMX37cEEkrm JwGX3HGftd4KAJvhb9H0NIjGXD70FU0pjm/BqwXgLuXa61ostZq5GNX74i+svL+uL2sK M12DdeZCL5EPUhIyVcYbH2Y2uyi57vCOr3BO/DOOyGZalWjTJavofSsQhKlnVtMSR8p0 X+YP8VnoZK0B7rC3BmFVI5PlhgVI9jF+xYxyBCNscvYFysDZGrLHR2kWg/qavPyRdOA1 BOIA== X-Gm-Message-State: AOAM531iyA7cCROqBfcZa8ZM2NO0JkvEB1IbEj53AHdmpSqSKrt1TXhW IjRe6inSnLxWAW4F/A70qZC3GZg2q+DKLb8vhCY= X-Google-Smtp-Source: ABdhPJwmgzPjauj1AN6F9qBmmte6htvkItEmGsE9UsDvF8qpmZXTaDhNeWnvwWAu6zKcPASEnM1DqYsnZDZvEvdxNiU= X-Received: by 2002:a1f:1b82:: with SMTP id b124mr13618448vkb.5.1607365954575; Mon, 07 Dec 2020 10:32:34 -0800 (PST) MIME-Version: 1.0 References: <20201205210351.DB78E2904420@ary.qy> <28759E60-3A00-4D25-9490-34495B96EE10@bluepopcorn.net> <9c23d850-4164-1320-1c25-40554c1f64b@taugh.com> In-Reply-To: From: "Murray S. Kucherawy" Date: Mon, 7 Dec 2020 10:32:22 -0800 Message-ID: To: Dotzero Cc: Michael Thomas , IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000bf1fcb05b5e40cb7" Archived-At: Subject: Re: [dmarc-ietf] ARC vs reject X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 07 Dec 2020 18:32:47 -0000 --000000000000bf1fcb05b5e40cb7 Content-Type: text/plain; charset="UTF-8" On Mon, Dec 7, 2020 at 4:05 AM Dotzero wrote: > I've asked here and in other places that validators/receivers consuming > ARC headers provide data regarding the results of such consumption. To date > we have not seen any data provided by participants in the ARC experiment. > It may be that ARC is a useful standard or it may not be. So far I'm seeing > a lot of supposition and speculation but no useful data for evaluation. > I wonder if we might ask our compatriots at M3AAWG if they might be willing or able to undertake a data collection project in this area. Most of the ARC proponents are also participants there. -MSK --000000000000bf1fcb05b5e40cb7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Dec 7, 2020 at 4:05 AM Dotzero &l= t;dotzero@gmail.com> wrote:
=
I've asked here and in other places that valid= ators/receivers consuming ARC headers provide data regarding the results of= such consumption. To date we have not seen any data provided by participan= ts in the ARC experiment. It may be that ARC is a useful standard or it may= not be. So far I'm seeing a lot of supposition and speculation but no = useful data for evaluation.

I wonder = if we might ask our compatriots at M3AAWG if they might be willing or able = to undertake a data collection project in this area.=C2=A0 Most of the ARC = proponents are also participants there.

-MSK
--000000000000bf1fcb05b5e40cb7-- From nobody Mon Dec 7 10:34: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 42A583A0AE8 for ; Mon, 7 Dec 2020 10:34:03 -0800 (PST) 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 uvooAbqt6AmX for ; Mon, 7 Dec 2020 10:34:02 -0800 (PST) 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 DDD6D3A089A for ; Mon, 7 Dec 2020 10:33:52 -0800 (PST) Received: by mail-ua1-x92f.google.com with SMTP id x13so4786575uar.4 for ; Mon, 07 Dec 2020 10:33:52 -0800 (PST) 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=GW+vIuENvnqwVrkW2lvU06qzclvv8jGlmX4dXoFjchk=; b=vRB/zFdoaykoXIiabGjVg9DWPsTKkAKeZT1FsR+4loznvEr47mQDVUPvjJP6U7w+7W NlIy6cVFBuwTAhm/2MMHkvju63HO8LnoK4d1kH1HOQ2I3g1CE7qEaDgey7TCFWmCLJEt U5g2COxpLvfSEGvpRajZjC75CB4zP3rQmh4BuQ9s6U4kTALcubhME3IdIuf8tPxYxK1y fnYlm2DtYwZYjq82OBxTL9svnGJRJv9wR4a/kkk3kVJ+OinC2AtTM+DMl6vQgZYX14iE lQeF1hI5Ywx85nVoKd4Tch2XC2pc1mtrfKp2G0W3de8fuFT9wtrEpTTpTG9MMN3weUVb iVoA== 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=GW+vIuENvnqwVrkW2lvU06qzclvv8jGlmX4dXoFjchk=; b=mX4v9VfTYniKFjbpdDKABeOJWdwOVpIRmtddAiQrMm36zqjKsFoz/bAEj033UeJLSa O2HhXbdupoe8mdHQGOjUhJpkfaq9a6wlwYVMqgr/SbqXueCGqieE4ls6ETQJO49gjHOg offaVHtZMb74Z+k0r+PVUYmN6PcVXeu51I2p5LRVhMxAm+p9Ln++2hwxt6Lbvm0y3COl 7UMTsU3v/AYTKpaHwi8idK5427IjA97qGjRCiSCQocTbinn1NM7bYpuuvwrws5l4mfp8 mivqKk2yrgX/cLtj0c9FdQSTz1Ak72NPEMfn1xcE7wlrNq0A8JcKe+WMUQzgLKOtENnN y+1A== X-Gm-Message-State: AOAM533xPxJMRBt5BvX2w74qZlO6dNSC8KsloaJHppviYJc4KQuAfoOL vrRrq0jIbHcAosF9QnTtvKgghCeG7ewux+YC8j6EmJVKyI4= X-Google-Smtp-Source: ABdhPJzJW9tTExvFSDx6VDMiGGQYg25AN2weJHl9wBO4Zq67o3Kpeoxfgm5bp6KZ/w7GucZkELdyUYgLYkVQk2lLj9M= X-Received: by 2002:ab0:67d4:: with SMTP id w20mr12687347uar.47.1607366031777; Mon, 07 Dec 2020 10:33:51 -0800 (PST) MIME-Version: 1.0 References: <20201205210351.DB78E2904420@ary.qy> <28759E60-3A00-4D25-9490-34495B96EE10@bluepopcorn.net> <9c23d850-4164-1320-1c25-40554c1f64b@taugh.com> <83dc465e-b857-b22b-b2f2-2d7ba4d74955@mtcc.com> In-Reply-To: <83dc465e-b857-b22b-b2f2-2d7ba4d74955@mtcc.com> From: "Murray S. Kucherawy" Date: Mon, 7 Dec 2020 10:33:40 -0800 Message-ID: To: Michael Thomas Cc: IETF DMARC WG Content-Type: multipart/alternative; boundary="00000000000059240605b5e411ae" Archived-At: Subject: Re: [dmarc-ietf] ARC vs reject X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 07 Dec 2020 18:34:10 -0000 --00000000000059240605b5e411ae Content-Type: text/plain; charset="UTF-8" On Mon, Dec 7, 2020 at 8:59 AM Michael Thomas wrote: > Btw, what is PSD? > A working group document: https://datatracker.ietf.org/doc/draft-ietf-dmarc-psd/ -MSK --00000000000059240605b5e411ae Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Dec 7, 2020 at 8:59 AM Michael Th= omas <mike@mtcc.com> wrote:
<= /div>
=20 =20 =20
Btw, what is PSD?

=
-MSK
--00000000000059240605b5e411ae-- From nobody Mon Dec 7 10:39: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 32F103A00F7 for ; Mon, 7 Dec 2020 10:39:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.651 X-Spam-Level: X-Spam-Status: No, score=-1.651 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mtcc-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6VkuIqbZdDZI for ; Mon, 7 Dec 2020 10:39:32 -0800 (PST) Received: from mail-pj1-x1030.google.com (mail-pj1-x1030.google.com [IPv6:2607:f8b0:4864:20::1030]) (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 D21663A00D9 for ; Mon, 7 Dec 2020 10:39:32 -0800 (PST) Received: by mail-pj1-x1030.google.com with SMTP id v1so106741pjr.2 for ; Mon, 07 Dec 2020 10:39:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mtcc-com.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=4gGhr9nvUG9nsAS4CJ6/eUHhtBOzxbudBsJRV52QjEs=; b=GQS6irUjAb5z2aE6azr8JV4OBEhzMlI1tQNBC4tNTg4NAA2mWPztMgorFb1Pml55dI gnL7PX5GEvZsUE/2gYBRw4mHM/A7fDyZwHn6vqkboeHmm8ZTDP2vRLYcJQxMgr6B4Ki3 9Faozttgo6/Q56TPzaCDwLUHppj7WK6SXhBvjZjCCPqvXeSfxNOA6yG71nRRHSuNeWNi tBzq/WdHZdeLrNNJE2G6o6wIp7LiIoxTgPIDuFFtu0GJ/kgh5G0mlBJi8T2lDgexyME+ GcwMxVoj0hHDoiaR3PJnZ3CzVBUXYM+Qju0R5ExxSRoLn1lySzRIxJKVIU+jmyBk8MZj J/Cg== 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=4gGhr9nvUG9nsAS4CJ6/eUHhtBOzxbudBsJRV52QjEs=; b=TEzJ+HrAP2U64pflZnHlNdyBVO6LNUTY4hVIzQ1SqbOYVe5AM8vD2n9XfqiXKg1P+z y5ADMiaQyzOpPaKTzBY1njXEVHDtr2K6QtF/iTxKAU+b2W9vjBA28vl/OA8PVY/V/BU4 WJU5wyJABvjb5DVt9nO6S1w76A3VmtONIlpwzfqjedKDDLNRmw0Bs46GCw3MvL392EX0 jPMFMKmCda/gxTuJfDQhwlrslUEs41PvM/bIFZSnhTuaIJ+IT6JgXD4eV6H+wxyOpJe3 ghOmdyn9OM8+y5gS7xogCl5n6IbDHMAk35aJyX8UYKgtpBapCYSSao3aSEUUcDjiIV1F leZg== X-Gm-Message-State: AOAM530qqAWY8tFgHmirePy4WUcIUAO7y8nk3ttGCo0Nc2zVvT8P+4Fc vuV+oVqbn3en2/6WoxU6rFxwl9cpF/jrVQ== X-Google-Smtp-Source: ABdhPJyXqGSLfKJ51aYdiG85iy/uoLNtnGdDo8AV4AmrJJdaBpK5WERg+9wVmaVm7C2Lif8JOEgqQA== X-Received: by 2002:a17:90a:9d88:: with SMTP id k8mr121777pjp.141.1607366371586; Mon, 07 Dec 2020 10:39:31 -0800 (PST) Received: from mike-mac.lan (107-182-41-154.volcanocom.com. [107.182.41.154]) by smtp.gmail.com with ESMTPSA id 21sm7010317pfx.84.2020.12.07.10.39.30 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 07 Dec 2020 10:39:30 -0800 (PST) To: "Murray S. Kucherawy" , Dotzero Cc: IETF DMARC WG References: <20201205210351.DB78E2904420@ary.qy> <28759E60-3A00-4D25-9490-34495B96EE10@bluepopcorn.net> <9c23d850-4164-1320-1c25-40554c1f64b@taugh.com> From: Michael Thomas Message-ID: Date: Mon, 7 Dec 2020 10:39:29 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------18770DA7B10768865AA80786" Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] ARC vs reject X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 07 Dec 2020 18:39:34 -0000 This is a multi-part message in MIME format. --------------18770DA7B10768865AA80786 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 12/7/20 10:32 AM, Murray S. Kucherawy wrote: > On Mon, Dec 7, 2020 at 4:05 AM Dotzero > wrote: > > I've asked here and in other places that validators/receivers > consuming ARC headers provide data regarding the results of such > consumption. To date we have not seen any data provided by > participants in the ARC experiment. It may be that ARC is a useful > standard or it may not be. So far I'm seeing a lot of supposition > and speculation but no useful data for evaluation. > > > I wonder if we might ask our compatriots at M3AAWG if they might be > willing or able to undertake a data collection project in this area.  > Most of the ARC proponents are also participants there. > What I'm particularly curious about is what the difference is with the arc auth-res on the filtering decisions. Why would a decision turn on that result? That's something I've been trying to understand, but haven't managed to get. Naively it seems like it could be useful, but is it in reality? Like can somebody show some A-B kind of examples, and whether or not they are statistical noise? Mike --------------18770DA7B10768865AA80786 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit


On 12/7/20 10:32 AM, Murray S. Kucherawy wrote:
On Mon, Dec 7, 2020 at 4:05 AM Dotzero <dotzero@gmail.com> wrote:
I've asked here and in other places that validators/receivers consuming ARC headers provide data regarding the results of such consumption. To date we have not seen any data provided by participants in the ARC experiment. It may be that ARC is a useful standard or it may not be. So far I'm seeing a lot of supposition and speculation but no useful data for evaluation.

I wonder if we might ask our compatriots at M3AAWG if they might be willing or able to undertake a data collection project in this area.  Most of the ARC proponents are also participants there.

What I'm particularly curious about is what the difference is with the arc auth-res on the filtering decisions. Why would a decision turn on that result? That's something I've been trying to understand, but haven't managed to get. Naively it seems like it could be useful, but is it in reality? Like can somebody show some A-B kind of examples, and whether or not they are statistical noise?

Mike

--------------18770DA7B10768865AA80786-- From nobody Mon Dec 7 10:40: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 A936B3A0114 for ; Mon, 7 Dec 2020 10:40:41 -0800 (PST) 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 V1okBUZlrUwf for ; Mon, 7 Dec 2020 10:40:38 -0800 (PST) Received: from mail-ua1-x936.google.com (mail-ua1-x936.google.com [IPv6:2607:f8b0:4864:20::936]) (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 C07393A00D9 for ; Mon, 7 Dec 2020 10:40:38 -0800 (PST) Received: by mail-ua1-x936.google.com with SMTP id n18so4791276ual.9 for ; Mon, 07 Dec 2020 10:40:38 -0800 (PST) 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=rTA4nfAmBD7NNHqayuB6ibiQEA27HvaVaybc2ozC5jA=; b=WWlFEYOhV4NmkDbduBtdxGaqopZZ/Cs7/EX0FxiZ2zX259yTv0AbP7+AwC/KuwhXK6 DiR7KMP8f7xHhSWpemOVxHq/XA9fGoLjdUHJVaxmAB1OEf1+JTauHIAXPgif3UQzl+OD P6tGhiVsUQ3is3DM1KCj1Y/Ea2GDELPwWH/5FEaolZf7PNJ2ziBJRvEDw1lq/b0y3/A7 FCEJgUuHjysM8AUAgzyJh5l0uYGzw2NbEmSyGfJ7z6rySAxPYgWEUnDE+JkRGzaKseTd 2nUX+NR5VRZ3cpB7vM3554Uwn15O0wfv5rmqwHCw1z9cDPTgWyGJ8pL+bHuFyaqplmI4 Vm7w== 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=rTA4nfAmBD7NNHqayuB6ibiQEA27HvaVaybc2ozC5jA=; b=KNyTpoW4Mqs9lIiJwvP7lGuRYocWaZDcYtZSZuSyf/ZptzpHzEabX7lwXykQ8UvN1Z gRJYYAV7Z5utSzEwYgKSNE1O+8VvqZimXDn0iwlBFchULMu6mN7BObiZPbyl+HM5/RKX x9/wTArXePq4iG4WCJTVo7RCVXi8jIYQCRfK1k/nIXA/MDtJgB0tKJOqhAkj6tfZDb7U w9AKfBfO9GvXZMsFkUvFe9LQUcKAyQeK6JK0pZlrM9cktCD/rBdkgKR/KnB7RNL0rIEz 0f+0GaDc3cuofuPirohFI6msbTxdZpgXZ27w+8ybyE4+lfokXa5zQHxsEuwf0ARM3Mdl B2jA== X-Gm-Message-State: AOAM531bUusznyoNVhjlOQ523aB9z8ZPT7EGoONjSe9c0wv4nM9HHm8H 0H9HUwHwfU5Flc3bWz199eheOW5U9grAjn99So305Q== X-Google-Smtp-Source: ABdhPJwZrvkLgFnbGq5PUz0rUD0ELG0Bku9clvYy+AQzk3sMXnm4zHvycSN1xzZE8Wm11ZzHakY3q79WSS5BIF7sIzQ= X-Received: by 2002:ab0:7504:: with SMTP id m4mr13176939uap.34.1607366437578; Mon, 07 Dec 2020 10:40:37 -0800 (PST) MIME-Version: 1.0 References: <20201205210351.DB78E2904420@ary.qy> <28759E60-3A00-4D25-9490-34495B96EE10@bluepopcorn.net> <9c23d850-4164-1320-1c25-40554c1f64b@taugh.com> In-Reply-To: From: Seth Blank Date: Mon, 7 Dec 2020 10:40:26 -0800 Message-ID: To: "Murray S. Kucherawy" Cc: Dotzero , IETF DMARC WG , Michael Thomas Content-Type: multipart/alternative; boundary="000000000000893fba05b5e42978" Archived-At: Subject: Re: [dmarc-ietf] ARC vs reject X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 07 Dec 2020 18:40:42 -0000 --000000000000893fba05b5e42978 Content-Type: text/plain; charset="UTF-8" On Mon, Dec 7, 2020 at 10:34 AM Murray S. Kucherawy wrote: > On Mon, Dec 7, 2020 at 4:05 AM Dotzero wrote: > >> I've asked here and in other places that validators/receivers consuming >> ARC headers provide data regarding the results of such consumption. To date >> we have not seen any data provided by participants in the ARC experiment. >> It may be that ARC is a useful standard or it may not be. So far I'm seeing >> a lot of supposition and speculation but no useful data for evaluation. >> > > I wonder if we might ask our compatriots at M3AAWG if they might be > willing or able to undertake a data collection project in this area. Most > of the ARC proponents are also participants there. > This data collection is taking place at M3AAWG; Kurt Andersen is leading, with myself and Todd Herr supporting. However, this got slowed dramatically due to COVID-- we won't realistically see data that's useful to this working group for another few months. In the meantime, ARC discussions continue between many international receivers, and the DMARC WG chairs are being kept in the loop. Once there's something material to bring back, that will happen publicly. > -MSK > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > -- *Seth Blank* | VP, Standards and New Technologies *e:* seth@valimail.com *p:* 415.273.8818 This email and all data transmitted with it contains confidential and/or proprietary information intended solely for the use of individual(s) authorized to receive it. If you are not an intended and authorized recipient you are hereby notified of any use, disclosure, copying or distribution of the information included in this transmission is prohibited and may be unlawful. Please immediately notify the sender by replying to this email and then delete it from your system. --000000000000893fba05b5e42978 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Dec 7, 2020 at 10:34 AM Murray S.= Kucherawy <superuser@gmail.com> wrote:
I'v= e asked here and in other places that validators/receivers consuming ARC he= aders provide data regarding the results of such consumption. To date we ha= ve not seen any data provided by participants in the ARC experiment. It may= be that ARC is a useful standard or it may not be. So far I'm seeing a= lot of supposition and speculation but no useful data for evaluation.

I wonder if we might ask our compatriots = at M3AAWG if they might be willing or able to undertake a data collection p= roject in this area.=C2=A0 Most of the ARC proponents are also participants= there.

This data collect= ion is taking place at M3AAWG; Kurt Andersen is leading, with myself and To= dd Herr supporting. However, this got slowed dramatically due to COVID-- we= won't realistically see data that's useful to this working group f= or another few months. In the meantime, ARC discussions continue between ma= ny international receivers, and the DMARC WG chairs are being kept in the l= oop. Once there's something material to bring back, that will happen pu= blicly.

=C2=A0
=
-MSK
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc


--

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


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

--000000000000893fba05b5e42978-- From nobody Mon Dec 7 10:41:06 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C17883A00E0 for ; Mon, 7 Dec 2020 10:41:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.65 X-Spam-Level: X-Spam-Status: No, score=-1.65 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, 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=mtcc-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AxgAFs06cfCo for ; Mon, 7 Dec 2020 10:41:03 -0800 (PST) Received: from mail-pg1-x52e.google.com (mail-pg1-x52e.google.com [IPv6:2607:f8b0:4864:20::52e]) (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 EE2BC3A0114 for ; Mon, 7 Dec 2020 10:41:02 -0800 (PST) Received: by mail-pg1-x52e.google.com with SMTP id m9so9657998pgb.4 for ; Mon, 07 Dec 2020 10:41:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mtcc-com.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=CnX+aNg4e1t5IufibbWum2pHmbtAzRUXRzeOMb9kdOA=; b=hp4FIsB/IchG0n2/cCpBllOW61CvLcsFglsXtbTLpDHUfjzsd8rZyrLVTa5V5mlXFF 5MKHd17tbKTTQtYt4hof611qt6b5iMvO5ijdSbDdPNsEgfSJLeVHR08hvsrIcKq7CIOW YdJS6txRcxwzRufgZ6OTmd8ebPNyd8ROk0RFCmCcb3iOI3Vs3/lkL5yooqiVr/6NJw5U 04TgFNpf0PZ4qNfEpMMl6if3T+4tvF6rY+FfWh4WVMKM9b7DpqPLUPFRcIuXzcwhB58+ wrekdfylilB198szrAoUy+H1Vx7z+GREYAXrm2oiewyfOHQdVJyHyHDHebI7ryCH88gg NdWQ== 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=CnX+aNg4e1t5IufibbWum2pHmbtAzRUXRzeOMb9kdOA=; b=MSj7PtfGDKyCrLpi8OWp177AljzyVk3VD3qjIr6BTROO6CX1Rs3lVdPjjvlkm1Hpy8 nrJNdIMPHsaZUWTjVo5UCkfNHACyDep/a2wiYL0C8uS6yqXMZ+AEG04w0k+JfVWfoH8a UZ7RKQGek8JZFaLAXOuk2VA5zp/0of6/s0Ae5NxB4GMY/oAtzibqAnW9a0orNKOKYyZp pcUPAeTiG+tiP835z7Q/5jpV9g5Jum8iszjpriwm0ODu8ofTtvZYqn+w6PNr9mpt7Rln jfiuskywwkmYZoDHCVnkcwIDOQNItl8kGUmTwnVLV5WZz7dn10yiI4xM5jucm1Wj6Y4H GTuw== X-Gm-Message-State: AOAM533rbWZfOprTJdGP32idmdFK6U9sGCoNUSOUe+NR8z1Wc4tKqICS 0IELqW9xd+Ab14V0H3iSlLv65IsRr5RetA== X-Google-Smtp-Source: ABdhPJwkdReiOyC/xRMPman8XvPAxyGqQ9lUMU9EhY//aCwXYjpjWjdUjPUsLc5caLxPyhpOIhza5A== X-Received: by 2002:a17:902:56a:b029:d7:ced2:60eb with SMTP id 97-20020a170902056ab02900d7ced260ebmr17528233plf.24.1607366461904; Mon, 07 Dec 2020 10:41:01 -0800 (PST) Received: from mike-mac.lan (107-182-41-154.volcanocom.com. [107.182.41.154]) by smtp.gmail.com with ESMTPSA id j9sm14694840pfi.116.2020.12.07.10.41.00 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 07 Dec 2020 10:41:01 -0800 (PST) To: "Murray S. Kucherawy" Cc: IETF DMARC WG References: <20201205210351.DB78E2904420@ary.qy> <28759E60-3A00-4D25-9490-34495B96EE10@bluepopcorn.net> <9c23d850-4164-1320-1c25-40554c1f64b@taugh.com> <83dc465e-b857-b22b-b2f2-2d7ba4d74955@mtcc.com> From: Michael Thomas Message-ID: Date: Mon, 7 Dec 2020 10:41:00 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------EC5D0433A19410FD3DDB2AE7" Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] ARC vs reject X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 07 Dec 2020 18:41:05 -0000 This is a multi-part message in MIME format. --------------EC5D0433A19410FD3DDB2AE7 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 12/7/20 10:33 AM, Murray S. Kucherawy wrote: > On Mon, Dec 7, 2020 at 8:59 AM Michael Thomas > wrote: > > Btw, what is PSD? > > > A working group document: > https://datatracker.ietf.org/doc/draft-ietf-dmarc-psd/ > > > Oh that. I figured out the acronym and obviously immediately forgot about it. Graci. Mike --------------EC5D0433A19410FD3DDB2AE7 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit


On 12/7/20 10:33 AM, Murray S. Kucherawy wrote:
On Mon, Dec 7, 2020 at 8:59 AM Michael Thomas <mike@mtcc.com> wrote:
Btw, what is PSD?



Oh that. I figured out the acronym and obviously immediately forgot about it. Graci.

Mike

--------------EC5D0433A19410FD3DDB2AE7-- From nobody Mon Dec 7 11:20:12 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A47843A0816 for ; Mon, 7 Dec 2020 11:20:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.851 X-Spam-Level: X-Spam-Status: No, score=-1.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iecc.com header.b=egfdemXr; dkim=pass (2048-bit key) header.d=taugh.com header.b=MW1Exrlw Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q2FKRhli98SN for ; Mon, 7 Dec 2020 11:20:02 -0800 (PST) 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 C25453A084D for ; Mon, 7 Dec 2020 11:20:01 -0800 (PST) Received: (qmail 94607 invoked from network); 7 Dec 2020 19:20:00 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=17186.5fce8060.k2012; bh=x0wt2LKelK32d5mkFeYsceHufhrUOREnd/xXdUFFgCc=; b=egfdemXrwmjvtzVlwoeWUofbmom0yMOsWseE0SAo9feLUTr+Mxcsenknt9CJFAePIZDM/DCarUHA59OsLI8T0IIYWdtadPB1x6ysDGQXvRkuVMhhQDjs/frNGBNXePM5jabYB+mgcw9hr1ptwMUtspbqT+R1fjH0tfMJA9Qo9wi55R7klgHkzlWe0yWkqGO4wHszIKvScnETcqJTTM1YUU/V2dkQ3os1je6OvHUmDvYQydcWSe5XuHvSGq8gf7UZ4vKbwQyVNQrwHVSHL8TiFrPwPiP4Prm5KuM+dUfEyy/lg8UftBS9Uw0ErSUooMvJH0/I2fUrRZw7lg2tTYFWvQ== DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=17186.5fce8060.k2012; bh=x0wt2LKelK32d5mkFeYsceHufhrUOREnd/xXdUFFgCc=; b=MW1ExrlwTZGzPkVRnjMc0xJJUSRN9PIjYGHIV1YQ0nc8YjXA1ks7Mk3LNOChv2YBpavEEXuJKrOrXkOmsRHn9d03OH28yll2a4mkaYMFI8zZ2D5NvcDDCRCR61xeatF0OtOPSd2iE/cSJDQHFGEximeTz6QL703yVrLeETFmZqhLgvaHwEjahR6xlzU2tun5PZqtTOdzMS+jqr8U2a+6XnNcRWY23kHTlecu2VjZBaKGql5WhxHz0c6kNydQ6P8drkqGsWVkCr/7bKIQEJVjOHscZlp+1LF5wUC0GhbitgJNUdfLLuNfg6Y1QSf9oF7gckiPSMvoN0552kJSatwyJw== 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; 07 Dec 2020 19:19:59 -0000 Received: by ary.qy (Postfix, from userid 501) id 6D772292166A; Mon, 7 Dec 2020 14:19:59 -0500 (EST) Date: 7 Dec 2020 14:19:59 -0500 Message-Id: <20201207191959.6D772292166A@ary.qy> From: "John Levine" To: dmarc@ietf.org Cc: vesely@tana.it In-Reply-To: Organization: Taughannock Networks X-Headerized: yes Cleverness: minimal Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] ARC vs reject X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 07 Dec 2020 19:20:10 -0000 In article you write: > Compared with the use of "l=" tag (Section 8.2 of [RFC6376]), the > fact that footers are written in plain text ... They are? Some are, some are added as MIME parts. We really need to keep in mind that there is a lot of list management software with a vast array of configuration options. R's, John From nobody Mon Dec 7 11:25: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 B9D0F3A064E for ; Mon, 7 Dec 2020 11:25:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.651 X-Spam-Level: X-Spam-Status: No, score=-1.651 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, 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=mtcc-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fpg4tBqhD7WD for ; Mon, 7 Dec 2020 11:25:48 -0800 (PST) Received: from mail-pg1-x535.google.com (mail-pg1-x535.google.com [IPv6:2607:f8b0:4864:20::535]) (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 935A13A064A for ; Mon, 7 Dec 2020 11:25:48 -0800 (PST) Received: by mail-pg1-x535.google.com with SMTP id w16so9754032pga.9 for ; Mon, 07 Dec 2020 11:25:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mtcc-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=xN2W8PDHs9mi6Je9UNcJohYlM9yz5MsF/9tmCoEWg9Q=; b=1YjMeNpphKSy1/Kl+qwao91Fd85Y0FiqbPi/v2ClZZMJgwIlz09msd75VXjHeAoMdO C9xjYTnAFFHkii+JUiLrwNfEBMwjNKjxQj6YNx0ir02IQgyVCop1AFd67RmVMdUeRaqq AeDl2o4EsEV/cEFD2eQ83rA/aQeRcNvIwzS1xi3MRejvvVApG8O/3q4J0DeGVCz1wCnH xMQx1BoG9phWkK8QHEble2L+1V4MS/bjnKbHlUo0J9voPNtKQld/em0YdJ5QCot5FflZ 4PVCUeawL/ReyRTGqh4/1dkO36SxqlYbn+vl7TP95/4ZyBhzVZSltR4SH15AeyhOb3tl vzhA== 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=xN2W8PDHs9mi6Je9UNcJohYlM9yz5MsF/9tmCoEWg9Q=; b=mSVLFBsjYHuq6tFAVrgH/ICGAfNoYANQb0sehC/iOxenWUBgfRh0CbZSXUBLjj3Ata ZR2vjsAiS1xMVoQf2C1qQeN1MsdkKCIDk34wZUHNKZ2yIZmQQHINvntCqTN+IvfhYCt0 xMmGLUqWcPn2r+pGEsCciUVznaRcdiWDjGGwDw4H3uU/rPywRHoHq+CfpxALhHtBVYa6 MnbAvtACF78fbezTEFzI9NZe97P1sV/0aLBaQugHlTwND0LExxWnX5hq+34Ga5ECDIjM Y0kDEqaeP9uDeXHZgDmoEvCphS5wmbSz3/jmFtYYBxv9Ghjmqvri7bvb7SpwhPK+gj41 9byg== X-Gm-Message-State: AOAM5326XPWY+6LHB2q63w7bF8wDzC1G/QDZMroBVb46qdoE9EATWINT ARrIXG79G+shyLoM+M4kbuW3Na/fhX3w4A== X-Google-Smtp-Source: ABdhPJzNNoSqE1k+9EroHHhPaFXzqutpKk6W+KpkoEa3dt8d3kP40ApG8e1yAlm8QFcKJQT57NPhWA== X-Received: by 2002:a17:902:b209:b029:d8:e7a4:bf10 with SMTP id t9-20020a170902b209b02900d8e7a4bf10mr18073330plr.77.1607369147381; Mon, 07 Dec 2020 11:25:47 -0800 (PST) Received: from mike-mac.lan (107-182-41-154.volcanocom.com. [107.182.41.154]) by smtp.gmail.com with ESMTPSA id g33sm13309281pgm.74.2020.12.07.11.25.46 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 07 Dec 2020 11:25:46 -0800 (PST) To: dmarc@ietf.org References: <20201207191959.6D772292166A@ary.qy> From: Michael Thomas Message-ID: <3ce2c2cc-66ca-c3da-d67d-b45c919aa8fd@mtcc.com> Date: Mon, 7 Dec 2020 11:25:45 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 MIME-Version: 1.0 In-Reply-To: <20201207191959.6D772292166A@ary.qy> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] ARC vs reject X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 07 Dec 2020 19:25:50 -0000 On 12/7/20 11:19 AM, John Levine wrote: > In article you write: >> Compared with the use of "l=" tag (Section 8.2 of [RFC6376]), the >> fact that footers are written in plain text ... > They are? Some are, some are added as MIME parts. > > We really need to keep in mind that there is a lot of list management > software with a vast array of configuration options. This is why we need actual numbers instead of anecdotes about the long tail. We know that there is no silver bullet. Mailing lists who are configured in a way that causes their traffic to not get delivered can be configured in a way that will. It's not our problem. Mike From nobody Mon Dec 7 11:51: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 794973A07B3 for ; Mon, 7 Dec 2020 11:51:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.451 X-Spam-Level: X-Spam-Status: No, score=-1.451 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (2048-bit key) reason="fail (message has been altered)" header.d=iecc.com header.b=IMLQOO4x; dkim=fail (2048-bit key) reason="fail (message has been altered)" header.d=taugh.com header.b=fFAIyYk8 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lwLB0OwPhioz for ; Mon, 7 Dec 2020 11:51:15 -0800 (PST) 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 7DE163A0332 for ; Mon, 7 Dec 2020 11:51:15 -0800 (PST) Received: (qmail 2660 invoked by uid 100); 7 Dec 2020 19:51:13 -0000 Date: 7 Dec 2020 19:51:12 -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=a5c.5fce87b1.k2012; i=news@user.iecc.com; bh=RTA5cqnRlPwbqDpGeravUlenmVMj+DQEQHCA57qeI+Y=; b=IMLQOO4xHhRduAgj1hqtspRq63cQuuAbJL+iZCAy9GcbvsUhYMD+FoXUFiPIYEFcgvSSdOTV9SxaIcf1O42//a351+s0l4bdeTwk+hx0/q0DSNvSsnoMpfvKz47UTMtHzoO3VOh9cc1nN4a0fIXpgJe2ZXbhNeVtValOMmRRFAnAApcQIndOmQdlrNeqkXgUsmx8jL3sxtdiWmXwif+LUsS74TcTpF7YrpmkGXNWWtObmGhm8Yrm2E+gB2ZDuOvb1Wu2I2QR51pKItDMEiQGHprNnGB/GKdsVadnbhv98f8BGTPz+p9KS3BFVVIxnGLhl4BM2+nzV36JEZUlaSBZjQ== 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=a5c.5fce87b1.k2012; olt=news@user.iecc.com; bh=RTA5cqnRlPwbqDpGeravUlenmVMj+DQEQHCA57qeI+Y=; b=fFAIyYk8Z2T8zWZ5coGMIPwx2RKniggFqAP28xySFWTeK2cFQOI2VENEWWNm57sFJSXb+ORKJgh75TJWDKV9UaK7dUtgatXKkWYd+pMVmgH7wOw8366qwXiYeV//+4aqmWfd4+8+xz0RUpJARm3V6kPEd+OqegCUGAhiLr67rc8IeZe7Ze0avmeRiM04fMkKHJiyYghwHqWsaC20igOu+dIIY9e3yPQuRjLmL7Ns44xqD43jI7yJMkBC8jOu7g0u9hWq9yf0eCKQBqNCCSnwTHDfD38WcYnNPzwbHYWg1k2MMeCozCx/qdnBtOOviBBeZpbkHT84D2cGlxtHvJKypA== Organization: Taughannock Networks References: <0408ae98-e1c1-71fe-fdd4-8bc7a7c151d3@tana.it> In-Reply-To: <0408ae98-e1c1-71fe-fdd4-8bc7a7c151d3@tana.it> Cleverness: some X-Newsreader: trn 4.0-test77 (Sep 1, 2010) Originator: johnl@iecc.com (John Levine) Archived-At: Subject: Re: [dmarc-ietf] Ticket #28 - Failure report mail loops X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2020 19:51:18 -0000 In article , Alessandro Vesely wrote: >> 4. Some explicit loop prevention specification may be added. For example: >>> 4.1. send reports from a subdomain having a DMARC record without ruf=, or >>> 4.2. never send failure reports about failed reports. >> >> The latter, which is consistent with SMTP never generating a bounce about a >> bounce. > >However, SMTP has an operational definition of bounce, MAIL FROM:<>. Should we >take the same stance? That is, send failure reports with an empty bounce >address and never send failure reports to bounces or failure reports? We're talking about DMARC failures, not SMTP delivery failures. I don't see what the latter has to do with the former. 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 Mon Dec 7 11:58: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 B23EB3A0809 for ; Mon, 7 Dec 2020 11:58:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.851 X-Spam-Level: X-Spam-Status: No, score=-1.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iecc.com header.b=Nqs8zeB4; dkim=pass (2048-bit key) header.d=taugh.com header.b=cHUhaKFa Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A-sUYuchway9 for ; Mon, 7 Dec 2020 11:58:23 -0800 (PST) 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 0D5873A07B3 for ; Mon, 7 Dec 2020 11:58:22 -0800 (PST) Received: (qmail 3806 invoked from network); 7 Dec 2020 19:58:21 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=edc.5fce895d.k2012; bh=wd2guXw+Omey/MQ/xdVP+S3+vEo1bwkXMFwXs65uxhI=; b=Nqs8zeB4tx+WAd58TDl98wTkaiexy1vUbrVObeBJK/sOYEvc1XS67FIkVPZBuNV1FMqjiw6K45vcUGUKETpIuA3i3wQ5ymC9i9YQhB8Psc5cYpzULaq6UigpVrHm8DD0gcvhyaVzszZUqJI0fpMc9cTh+4DacKR2JOzWI8cKmclG2PajOJ9UyLIGZyOY9ecsYVmf4Hia0jYPmeahhMSf9z9UnJ8y4BFpdekXz5h2/nJFg+SKnkx0iF6d6GIVx5CbbPbeohaWT6m51PqZNYQruz7Wrsb9rxEFfCTzroTVR2+z7SAZk0ngEtlirswiqMzcBO93Z04sEvb0PeWwm7xjNA== DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=edc.5fce895d.k2012; bh=wd2guXw+Omey/MQ/xdVP+S3+vEo1bwkXMFwXs65uxhI=; b=cHUhaKFaEQMUKpvML67cMBrw/PyUbdR7zdCRKS5xtDd8eeGFK4FYQxyIeeMxfXJDPQlHJAD1Km9FLVJdstJCJKQv1pt7lJ+63JZWu7wOnHqkSdVhAqN7VILxAXcZfi9FoIPIJkOYFpkA80OI++PrLQmiKRDlahLNE9yHmyu+ToIela7TDe4qE69gyIjrU4DLdkoDoojtxeXmC6bdunQucRbjuwh/1HLmJIfyP3UpoUkr/pcJeD9c3jSlJsT7ixAOy+Unw273nbQCIZmL9Ry6nkQWHoqn/VIBE0VtCPw9g476FUfOyp7SnN/yuzV7wM8FSQAUSeK64dUS7aj9UU1wSw== 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; 07 Dec 2020 19:58:21 -0000 Received: by ary.qy (Postfix, from userid 501) id E471C2921A42; Mon, 7 Dec 2020 14:58:20 -0500 (EST) Date: 7 Dec 2020 14:58:20 -0500 Message-Id: <20201207195820.E471C2921A42@ary.qy> From: "John Levine" To: dmarc@ietf.org Cc: vesely@tana.it In-Reply-To: <0408ae98-e1c1-71fe-fdd4-8bc7a7c151d3@tana.it> Organization: Taughannock Networks X-Headerized: yes Cleverness: minimal Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] Ticket #28 - Failure report mail loops X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2020 19:58:25 -0000 In article <0408ae98-e1c1-71fe-fdd4-8bc7a7c151d3@tana.it> you write: >We would like to close this ticket by Dec 18, two weeks from now, so please get >on it. > >The ticket originated from John's comment, in May 2019: > > Apropos recent discussions, we could recommend that failure reports be > rate limited per recipient both to break loops and to deter indirect > mail bombing. >4. Some explicit loop prevention specification may be added. For example: >4.1. send reports from a subdomain having a DMARC record without ruf=, or >4.2. never send failure reports about failed reports. 4.0. Make your failure reports DMARC aligned. Looking at the failure reports in my file, all of the messages actually are aligned, so this is a solved problem. Other than the the possibility of indirect mail bombing via failure reports, which I believe has never happened, I don't understand what problem we are trying to solve here. Since the original comment was mine, I would suggest closing this one as nothing to fix. From nobody Mon Dec 7 13:00: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 956023A0B6F for ; Mon, 7 Dec 2020 13:00:43 -0800 (PST) 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 YmUXBv3q7vLt for ; Mon, 7 Dec 2020 13:00:41 -0800 (PST) Received: from mail-oi1-x229.google.com (mail-oi1-x229.google.com [IPv6:2607:f8b0:4864:20::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61E123A0B61 for ; Mon, 7 Dec 2020 13:00:41 -0800 (PST) Received: by mail-oi1-x229.google.com with SMTP id f132so2531749oib.12 for ; Mon, 07 Dec 2020 13:00:41 -0800 (PST) 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=ObrDJB7IymYpiSp9EF1V80dXSpFXuYWLhp7Heu7wB+0=; b=gKOw16w+/0I56ABYDNwLxq2mTxuOH3JaURZMGEW0Kn2+nFRcv960fdqG7kh2POdSIW 0moY+mJZPk/9hWfmmtHoEJBNkYw1h9vUKvmC5i6DzuQ80eN9ilN1LliqZF2Lv6SWsjXX XWMqiVL/9JmRxrEhgNGRQObRlmgeH2Gtvx22L47N6MsSKm/vBwzOWPTHDZCLuf4RqZe/ IwkXtVG2KJ0DcWPTysD3zkdTXn566i4qK8hKCrCEP0LzYOjkq6D3aLUzdjhId0D3ncgZ bN0AyL183/59agpCI1Rl6RCI0PxM/sKwkAn8r8WqPzjtkoT8ICpaa96K5Hh93w5Y5dUI 4WaA== 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=ObrDJB7IymYpiSp9EF1V80dXSpFXuYWLhp7Heu7wB+0=; b=hm9SOKvyUw+3XqKEKSsnsCXKPCc0cle59B/1hZyZ81RatAIVViGdCMvxnYW9bwAQxF rmWKNhnR2EIombA+ChaHQBx+dpCbRCNGQIgUXLuFcme/4UIXCRbatlfxgTlSATsQ7LeX F1DTL8qMogdYUVWQgaQ93SglowDDPPuWEyZLyH004K5gsloqfXH1WQYvhMwBZdXglWhm 6ItV3SPzEnWvWL2wThn0LV3nks5eXqBaezkJnGSTNaYK6PwlEF62ajyAhTjzWLkTCUZa YN2CLvaJp12fy1DscfatUVqDC+SxVyNHwAd7VuWMp+sl1dcbtN77aDMIUJUqLd3KBd8o XFgQ== X-Gm-Message-State: AOAM533tmhBXB+nT4s6vBqCldyATGBEt4QxyeGFc0FPJBKaeixrxHjEx EgseV/MsfvJbmjLIEtuwxQ2CSeWhxc/ViVPfKdsg87Uz X-Google-Smtp-Source: ABdhPJydvOtGK2PhSIvGXeA1gMKT444ZpKf43iWfi4siYBdVMCzy8DMno29AWwipn7ZQlu58rr/QeZZJ/50l+KHPQCk= X-Received: by 2002:aca:c3c6:: with SMTP id t189mr497412oif.21.1607374840664; Mon, 07 Dec 2020 13:00:40 -0800 (PST) MIME-Version: 1.0 References: <20201207191959.6D772292166A@ary.qy> <3ce2c2cc-66ca-c3da-d67d-b45c919aa8fd@mtcc.com> In-Reply-To: <3ce2c2cc-66ca-c3da-d67d-b45c919aa8fd@mtcc.com> From: Tim Wicinski Date: Mon, 7 Dec 2020 16:00:29 -0500 Message-ID: To: Michael Thomas Cc: IETF DMARC WG Content-Type: multipart/alternative; boundary="00000000000066161205b5e61e47" Archived-At: Subject: Re: [dmarc-ietf] ARC vs reject X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 07 Dec 2020 21:00:51 -0000 --00000000000066161205b5e61e47 Content-Type: text/plain; charset="UTF-8" On Mon, Dec 7, 2020 at 2:26 PM Michael Thomas wrote: > > On 12/7/20 11:19 AM, John Levine wrote: > > In article you write: > >> Compared with the use of "l=" tag (Section 8.2 of [RFC6376]), the > >> fact that footers are written in plain text ... > > They are? Some are, some are added as MIME parts. > > > > We really need to keep in mind that there is a lot of list management > > software with a vast array of configuration options. > > This is why we need actual numbers instead of anecdotes about the long > tail. We know that there is no silver bullet. Mailing lists who are > configured in a way that causes their traffic to not get delivered can > be configured in a way that will. It's not our problem. > > Are you talking about integrating ARC? Then you are correct, operational data. This is why until that happens, we're not talking about adding ARC into the DMARC flow, and it's why the ARC work is Out Of Scope in this WG. tim --00000000000066161205b5e61e47 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, Dec 7, 2020 at 2:26 PM Michael Thomas= <mike@mtcc.com> wrote:

On 12/7/20 11:19 AM, John Levine wrote:
> In article <b069e7c1-51a8-4550-76a9-c7e78f04c780@tana.it= > you write:
>>=C2=A0 =C2=A0 =C2=A0Compared with the use of "l=3D" tag (= Section 8.2 of [RFC6376]), the
>>=C2=A0 =C2=A0 =C2=A0fact that footers are written in plain text ...=
> They are?=C2=A0 Some are, some are added as MIME parts.
>
> We really need to keep in mind that there is a lot of list management<= br> > software with a vast array of configuration options.

This is why we need actual numbers instead of anecdotes about the long
tail. We know that there is no silver bullet. Mailing lists who are
configured in a way that causes their traffic to not get delivered can
be configured in a way that will. It's not our problem.


Are you talking about integrating ARC?=C2=A0 Then you are= correct, operational
data.=C2=A0 This is why until that happens, we're not talk= ing about=C2=A0adding ARC into
the DMARC flow, and it's why the ARC work is Out = Of Scope in this WG.

tim

--00000000000066161205b5e61e47-- From nobody Mon Dec 7 13: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 B51E33A0AA1 for ; Mon, 7 Dec 2020 13:07:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.649 X-Spam-Level: X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mtcc-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JXRqpVMc7d5X for ; Mon, 7 Dec 2020 13:07:24 -0800 (PST) Received: from mail-pf1-x42c.google.com (mail-pf1-x42c.google.com [IPv6:2607:f8b0:4864:20::42c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80CD33A0A96 for ; Mon, 7 Dec 2020 13:07:24 -0800 (PST) Received: by mail-pf1-x42c.google.com with SMTP id b26so11446394pfi.3 for ; Mon, 07 Dec 2020 13:07:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mtcc-com.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=dX7cgQfjhlwSJMnVGhxsOirI0gZgskGdlVMTlPfGr6A=; b=Fy/TDtAbYlcMgJKAVc7MKXkNvOfSdqjGPsHm7AW8va5U6/lA82GIaRjOtCgnQM1R1r B7boyV/HhMoz1i/+1+h5JCPOXIAtHUk6KP/Gk4gviqq4HC/PeaY3OZq2dmVayOo01E+l ljhpMqG2diFwdNiTeAh0GZv4QdIZTD2RvvP42s4+FyDXOx7mBZStwPrixdYOe601mslK sw+Eo9EZSC3DNhVKPWweKNaYKlsgdVW/SNpg6PtmoTVKFqXgWS5uNFxtQsH6eKKBRAsD DBM88gxXB8EbQ3bY8H3AWF5/JEmL0JMEa8xariWpe0sidFWzq6kvPV7trL6Qaqteog9S M9PA== 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=dX7cgQfjhlwSJMnVGhxsOirI0gZgskGdlVMTlPfGr6A=; b=LrfrDLdlpdnk2Oc6oLs5zQf/WMFNDpz/AIIvpLfqiLpLtTG4OeQk2nOtTG1CtiI50w xWyuYZn/fzOaHCXAmyN8eiwh75fzHaJDp6cBBKaHGQa1xzOf/YCNk01xQhMGSK0ontMY gPUz60Qkg2wM+BuZMdc0+MSSzbhJqP77I5n3dl/cBisRu+fZLu5xbOvYQGR1PgBezzii 7a6Jx2AP0zcEmSgFvSBrSDdWh9yBIqdFjSovxTDuW0Q8vXJWwj3QRr1FAd806MXVYtPR 9OAsxSLT9ABhPy1FcYfiicb3mDVZCGzTp6uInIqa3lLBy5BBlMoMtFx5m1E3nCQ0/XTo 5bBA== X-Gm-Message-State: AOAM532w+eCrJTI/+CzDB2rQGakAoX2KzufrCj6iVX3/WeSvHrQl0eWB iWPU35QDg3i5DMoiqhgssRv2EEY4DzZawg== X-Google-Smtp-Source: ABdhPJyBiT7eaQSFBTyonGfZq08HkZg5utm93LXjswbBcjdK5rCsg0oQH7zi2MGsw9+qHh49O/SCXQ== X-Received: by 2002:a17:902:7c92:b029:da:d86b:78be with SMTP id y18-20020a1709027c92b02900dad86b78bemr14686922pll.0.1607375241854; Mon, 07 Dec 2020 13:07:21 -0800 (PST) Received: from mike-mac.lan (107-182-41-154.volcanocom.com. [107.182.41.154]) by smtp.gmail.com with ESMTPSA id e3sm15924730pfe.154.2020.12.07.13.07.20 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 07 Dec 2020 13:07:21 -0800 (PST) To: Tim Wicinski Cc: IETF DMARC WG References: <20201207191959.6D772292166A@ary.qy> <3ce2c2cc-66ca-c3da-d67d-b45c919aa8fd@mtcc.com> From: Michael Thomas Message-ID: Date: Mon, 7 Dec 2020 13:07:19 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------148C1FC621EA4E4AD90FC273" Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] ARC vs reject X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 07 Dec 2020 21:07:26 -0000 This is a multi-part message in MIME format. --------------148C1FC621EA4E4AD90FC273 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 12/7/20 1:00 PM, Tim Wicinski wrote: > > > On Mon, Dec 7, 2020 at 2:26 PM Michael Thomas > wrote: > > > This is why we need actual numbers instead of anecdotes about the > long > tail. We know that there is no silver bullet. Mailing lists who are > configured in a way that causes their traffic to not get delivered > can > be configured in a way that will. It's not our problem. > > > Are you talking about integrating ARC?  Then you are correct, operational > data. This is why until that happens, we're not talking about adding > ARC into > the DMARC flow, and it's why the ARC work is Out Of Scope in this WG. > > Do you mean that it is out of scope wrt DMARC? I can understand that since it's an experiment. It would probably be best documented in the context of ARC itself and dealt with if it ever becomes standards track. In the mean time, reject should mean reject. As it turns out, rfc 7489 does seem to document the issue though. Mike --------------148C1FC621EA4E4AD90FC273 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit


On 12/7/20 1:00 PM, Tim Wicinski wrote:


On Mon, Dec 7, 2020 at 2:26 PM Michael Thomas <mike@mtcc.com> wrote:

This is why we need actual numbers instead of anecdotes about the long
tail. We know that there is no silver bullet. Mailing lists who are
configured in a way that causes their traffic to not get delivered can
be configured in a way that will. It's not our problem.


Are you talking about integrating ARC?  Then you are correct, operational
data.  This is why until that happens, we're not talking about adding ARC into
the DMARC flow, and it's why the ARC work is Out Of Scope in this WG.



Do you mean that it is out of scope wrt DMARC? I can understand that since it's an experiment. It would probably be best documented in the context of ARC itself and dealt with if it ever becomes standards track. In the mean time, reject should mean reject.

As it turns out, rfc 7489 does seem to document the issue though.

Mike

--------------148C1FC621EA4E4AD90FC273-- From nobody Mon Dec 7 13:41: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 30A3F3A0B50 for ; Mon, 7 Dec 2020 13:41:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.851 X-Spam-Level: X-Spam-Status: No, score=-1.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iecc.com header.b=ZCHtNALI; dkim=pass (2048-bit key) header.d=taugh.com header.b=BfAWx4p1 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hVoDMo2lPMb0 for ; Mon, 7 Dec 2020 13:41:35 -0800 (PST) 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 179FA3A0A42 for ; Mon, 7 Dec 2020 13:41:34 -0800 (PST) Received: (qmail 30632 invoked from network); 7 Dec 2020 21:41:34 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=77a5.5fcea18e.k2012; bh=WWJrA1P1JiOIZ2AVoL1YTyQICPFvZAJnRlANeyq0Pxg=; b=ZCHtNALIDfVkE4k5SEbwKf4QDZXlU1LNXmfkCVWPY3Yhj9sJiH1uw+SyzEa6i+BdBz107uZaSaesS4n+JeAjAQRUecVblhJqfCAavMMWUTWB7wESv3S+iGUKHcwahyqObtjY8QLN0IDITwX9rNpHexNW4kveKtSFQAhd0rM2JQzo+7oY3+VrvroUIosxRbBeRA7UqlXyY8p95rk8EBN1/8I1JNqz84M1ghkB+7+zO9c1A33Qt60l5ex60F60cxvW+R8tijq3rjq71MPVKvhd69jrzr72kwI0OYpe9qVpma8GxpwMTNU3PvDYzVoW4XqxtQ98FIgSNwPq3/cjkgcEkg== DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=77a5.5fcea18e.k2012; bh=WWJrA1P1JiOIZ2AVoL1YTyQICPFvZAJnRlANeyq0Pxg=; b=BfAWx4p1NGO5GQGwCFHCJ89y9k8ijiBRLw2g5ajrdVG6MTeTPCfJHs5biZc2WYoHOn5ijNbVA+34lPZxITIrIsZSIhdrlSom3HWRyuPCn6MYA0WlcbpvW+ITEgah/7RxUggmZgbGPT5Ssjh9PHuJXZ2bmp5lLMMaTF0ktuyWsm4qgj9u/AZvEPOb1hvvMGShfMnNA2SGzSObwcQLUXuDX7torFxIcJo5dPT6lqUbmLja0CcEGQVvrACz20pSfjZTWaKXgwFNiufsbtiexXbnx3c7t27hUU96tfP7CLW0rQQXQp1hZCS3+9y6GNHA1ve7FM4r3wdkDGtbK86dRl6lIg== 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; 07 Dec 2020 21:41:33 -0000 Received: by ary.qy (Postfix, from userid 501) id 2D5142922931; Mon, 7 Dec 2020 16:41:32 -0500 (EST) Date: 7 Dec 2020 16:41:32 -0500 Message-Id: <20201207214133.2D5142922931@ary.qy> From: "John Levine" To: dmarc@ietf.org In-Reply-To: Organization: Taughannock Networks X-Headerized: yes Cleverness: minimal Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] Ticket #42 - Expand DMARC reporting URI functionality X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 07 Dec 2020 21:41:37 -0000 >I don't understand the security or GDPR references. Well this is amusing. I wondered if anyone had ever implemented some version of the http reporting in early DMARC drafts, so I set up a new domain with a server that will accept POST or PUT requests and added its URI to my DMARC records. I didn't get any of those (the POSTs below are not to the right URI) but it's impressive how fast Russian bots started to probe it, within hours. This is not a reason to avoid https reporting. Every web site gets probed like this and so long as your web server rejects unknown URIs, they're harmless. After all, my e-mail reporting addresses get a certain amount of spam, too. R's, John 139.162.113.204 dmreport.abuse.net - [07/Dec/2020:03:15:11 -0500] "GET / HTTP/1.1" 404 719 "HTTP Banner Detection (https://security.ipip.net)" 192.241.209.169 dmreport.abuse.net - [07/Dec/2020:05:26:29 -0500] "GET / HTTP/1.1" 404 719 "Mozilla/5.0 zgrab/0.x" 192.241.237.68 dmreport.abuse.net - [07/Dec/2020:05:49:18 -0500] "GET /owa/auth/logon.aspx?url=https%3a%2f%2f1%2fecp%2f HTTP/1.1" 404 786 "Mozilla/5.0 zgrab/0.x" 91.241.19.84 dmreport.abuse.net - [07/Dec/2020:06:44:01 -0500] "POST /vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php HTTP/1.1" 404 823 "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.108 Safari/537.36" 91.241.19.84 dmreport.abuse.net - [07/Dec/2020:06:44:01 -0500] "POST /api/jsonws/invoke HTTP/1.1" 404 757 "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.108 Safari/537.36" 91.241.19.84 dmreport.abuse.net - [07/Dec/2020:06:44:07 -0500] "GET /vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php HTTP/1.1" 404 823 "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.108 Safari/537.36" 91.241.19.84 dmreport.abuse.net - [07/Dec/2020:06:44:07 -0500] "GET /index.php?s=/Index/\\think\\app/invokefunction&function=call_user_func_array&vars[0]=md5&vars[1][]=HelloThinkPHP21 HTTP/1.1" 404 858 "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.108 Safari/537.36" 91.241.19.84 dmreport.abuse.net - [07/Dec/2020:06:44:09 -0500] "GET /?XDEBUG_SESSION_START=phpstorm HTTP/1.1" 404 753 "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.108 Safari/537.36" 91.241.19.84 dmreport.abuse.net - [07/Dec/2020:06:44:11 -0500] "POST /mifs/.;/services/LogService HTTP/1.1" 404 779 "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.108 Safari/537.36" 91.241.19.84 dmreport.abuse.net - [07/Dec/2020:06:44:12 -0500] "GET /wp-content/plugins/wp-file-manager/readme.txt HTTP/1.1" 404 813 "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.108 Safari/537.36" 193.118.53.202 dmreport.abuse.net - [07/Dec/2020:11:45:14 -0500] "GET / HTTP/1.1" 404 719 "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.113 Safari/537.36" 67.205.149.169 dmreport.abuse.net - [07/Dec/2020:12:50:40 -0500] "GET / HTTP/1.0" 400 362 "-" 83.97.20.31 dmreport.abuse.net - [07/Dec/2020:14:46:30 -0500] "GET / HTTP/1.1" 404 723 "-" 185.141.63.14 dmreport.abuse.net - [07/Dec/2020:14:47:37 -0500] "GET / HTTP/1.1" 404 723 "libwww-perl/6.49" From nobody Mon Dec 7 13: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 B66923A0B71 for ; Mon, 7 Dec 2020 13:56:05 -0800 (PST) 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 VAi2kJwbSbwa for ; Mon, 7 Dec 2020 13:56:01 -0800 (PST) Received: from mail-io1-xd2d.google.com (mail-io1-xd2d.google.com [IPv6:2607:f8b0:4864:20::d2d]) (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 E24843A0B50 for ; Mon, 7 Dec 2020 13:55:55 -0800 (PST) Received: by mail-io1-xd2d.google.com with SMTP id p187so14936901iod.4 for ; Mon, 07 Dec 2020 13:55:55 -0800 (PST) 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=tLIWjVDIdta6U5Gqn7jftFrB+B+GikrMIiimSoPQMhg=; b=Rx3SzIoLC4/bShadVOjmK1LjQFv+3qGD1nNLiVmOzVsnDbhzgTIGTMPkUJgTqgE/CR IoEw4/X7byVnEk7oUvf9WT6jhJC+GFowYU5hJ7BdzuHKPV4SXSSdH4C+zRwwG0SW8jyr UkL4MPg85UjXzCBbE8CvlgMH4hCrx56IaBAS8= 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=tLIWjVDIdta6U5Gqn7jftFrB+B+GikrMIiimSoPQMhg=; b=Gda9IVo9Py7MIac8mbEwgxBIJsDkb2bJgV+PdTQra859o1VrQGFe9usA+BQkO64RDr fEt2GNpv5FUS5gZq+BhRD5AkCXyIEK0yvh93RuW8QPHUKAqy94mxiTVPkh32uZMxOGAX 6TH/pcs59swHp6RDwq5jZh2/rjVo/v6UntRqmrTOLoIbuWKMRGFS7ObFeP8YE03VDxev /HtiTXDha+xr7QrED/We5NQY+Lo70uwNbz/VRWME5g2KBn+5TChM31w/ZgVYXL1skHdH GktI7SmYgaAjjxvoMgBdLjgo3RXYwLXUGHXpZhUau+JYOkUhxWZi3ch4/ErJNOQcm1z9 P9PQ== X-Gm-Message-State: AOAM530xTUgsyJOWutag546DsH6/kKAXXY3EP54U+0NIeiDz3F2OXNhv 5PbHEcU4lMNBCrDYZy4P6TSPEVMR5Xh0tFSY18E6ng== X-Google-Smtp-Source: ABdhPJzjuZdUlqLA7+7jYyGyIle1pVq8AlRQMyOPOVv6h3LzyNh7WkizPCjvq/hUAJStKB46GL+mNUtl3Kfm3q+yHoM= X-Received: by 2002:a02:c9cc:: with SMTP id c12mr23635474jap.116.1607378154737; Mon, 07 Dec 2020 13:55:54 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: "Kurt Andersen (b)" Date: Mon, 7 Dec 2020 13:55:29 -0800 Message-ID: To: "Murray S. Kucherawy" Cc: John R Levine , IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000eeed2205b5e6e3ac" Archived-At: Subject: Re: [dmarc-ietf] Ticket #1 - SPF alignment X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 07 Dec 2020 21:56:06 -0000 --000000000000eeed2205b5e6e3ac Content-Type: text/plain; charset="UTF-8" On Sun, Dec 6, 2020 at 11:13 PM Murray S. Kucherawy wrote: > On Tue, Dec 1, 2020 at 2:17 PM John R Levine wrote: > >> We would like to close this ticket by Dec 15, two weeks from now, so >> short >> trenchant comments are welcome. >> >> Ticket #1 is about SPF alignment. We need to replace references to 4408 >> with 7408, ando clarify what if anything we do with SPF HELO checks if >> the MAIL FROM is null. One possibility is to say only MAIL FROM SPF >> counts, if you want to align your bounces, sign them. The other is to >> explicitly say that HELO alignment is OK on bounces. >> > > I have a slight preference for the first option. HELO is too arbitrary in > the protocol for me to put much value in using it in any of these systems. > There's a bit of an implementation detail though. If one is relying on an encapsulated ck_host() function then you may not know whether it checked the HELO or the MAIL FROM. Imposing a requirement like this from DMARC seems like it verges on a layering violation. --Kurt --000000000000eeed2205b5e6e3ac Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sun, Dec 6, 2020 at 11:13 PM Murray S.= Kucherawy <superuser@gmail.com> wrote:
We would like to clos= e this ticket by Dec 15, two weeks from now, so short
trenchant comments are welcome.

Ticket #1 is about SPF alignment.=C2=A0 We need to replace references to 44= 08
with 7408, ando clarify what if anything we do with SPF HELO checks if
the MAIL FROM is null.=C2=A0 One possibility is to say only MAIL FROM SPF <= br> counts, if you want to align your bounces, sign them.=C2=A0 The other is to=
explicitly say that HELO alignment is OK on bounces.
<= br>
I have a slight preference for the first option.=C2=A0 HELO i= s too arbitrary in the protocol for me to put much value in using it in any= of these systems.

There&= #39;s a bit of an implementation detail though. If one is relying on an enc= apsulated ck_host() function then you may not know whether it checked the H= ELO or the MAIL FROM. Imposing a requirement like this from DMARC seems lik= e it verges on a layering violation.

--Kurt=C2=A0<= /div>
--000000000000eeed2205b5e6e3ac-- From nobody Mon Dec 7 14:13: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 C99763A0B8B for ; Mon, 7 Dec 2020 14:13:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.851 X-Spam-Level: X-Spam-Status: No, score=-1.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iecc.com header.b=GH4Rgmi6; dkim=pass (2048-bit key) header.d=taugh.com header.b=GS9K+iQO Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ADZqrWurY7H5 for ; Mon, 7 Dec 2020 14:13:47 -0800 (PST) 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 2DC0B3A0B6D for ; Mon, 7 Dec 2020 14:13:46 -0800 (PST) Received: (qmail 37525 invoked from network); 7 Dec 2020 22:13: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:cleverness; s=9293.5fcea919.k2012; bh=dBn8pwO7BHB8598OWzzQqTERK0RnbFeVoyysDbF9y3Y=; b=GH4Rgmi6edNn2J6ALOFP0h2Svx5coH3FfkUND2PzAzd9RkZVwzJip+OpF+Drusj/Bznaxim98d+9fIkqXCT7iYaR9gXfLI3Op6xIwGTG5vCS2u6vbgRMkc17GD/zF1Za+JYFuvMsYx/Q7l/G1LuM0RjTX8Agtm0K6UCi/jKkQguEyTBhenTon1XnWyH3+SBURuKGNg3JVssOT6xM24k3v+kTJHZLjvUb0Zp63ulSWUl3gaYpL4xPtDFok5DPUj5uZO0abF46ubnK1siMqGWpd3/5jb5qnvJTG0jswD1K26x/blEHrnUWmOO2cvf8NfT/+N5te7VtRTec4FWLHIk6iw== DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=9293.5fcea919.k2012; bh=dBn8pwO7BHB8598OWzzQqTERK0RnbFeVoyysDbF9y3Y=; b=GS9K+iQOsiEgiIbcfccAYBanL3oTgbF6jKdNi/WIccleCa53YP5hf1jUKMk4a+pvJoghPMHgWjw2DoQayySkTg9UzDUdu6ndVBs5XGfLLpP566UY3a87Ku5cMMmUtTevnAw9BfnDlU/QKwHyDnApsH854vyMOafVVnPOyohzpkhHAE3Y3d1oiSIzrToOQm7iTj3/DYQq6xnaLiQbKz9Hd86UpeybccGN32BuMjcW1yjYrurZUyhuxB6afVu2gZpn/JpFP1LUL8vJpQ0gztuGcVZHjXE2+9mQjWuuazj/cGPePnIVmkmiUxDYzFDbROVfb2mx7j9Ujc+7pf/rBhw7OA== 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; 07 Dec 2020 22:13:45 -0000 Received: by ary.qy (Postfix, from userid 501) id 09DD72922E4A; Mon, 7 Dec 2020 17:13:44 -0500 (EST) Date: 7 Dec 2020 17:13:44 -0500 Message-Id: <20201207221345.09DD72922E4A@ary.qy> From: "John Levine" To: dmarc@ietf.org Cc: kboth@drkurt.com In-Reply-To: Organization: Taughannock Networks X-Headerized: yes Cleverness: minimal Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] Ticket #1 - SPF alignment X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 07 Dec 2020 22:13:50 -0000 In article you write: >> I have a slight preference for the first option. HELO is too arbitrary in >> the protocol for me to put much value in using it in any of these systems. > >There's a bit of an implementation detail though. If one is relying on an >encapsulated ck_host() function then you may not know whether it checked >the HELO or the MAIL FROM. Imposing a requirement like this from DMARC >seems like it verges on a layering violation. You should be able to look at the bounce address and if it's null, skip the SPF check. No need to peek inside SPF for that. R's, John From nobody Mon Dec 7 14:17: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 BD0443A0B92 for ; Mon, 7 Dec 2020 14:17:53 -0800 (PST) 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, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=-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=marcbradshaw.net header.b=Yu5B5Ixk; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=p40Y3EnM Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yjyRr9yIMasF for ; Mon, 7 Dec 2020 14:17:52 -0800 (PST) Received: from wout1-smtp.messagingengine.com (wout1-smtp.messagingengine.com [64.147.123.24]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF1DF3A0B6D for ; Mon, 7 Dec 2020 14:17:51 -0800 (PST) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.west.internal (Postfix) with ESMTP id 85EAC13DD for ; Mon, 7 Dec 2020 17:17:49 -0500 (EST) Received: from imap10 ([10.202.2.60]) by compute3.internal (MEProxy); Mon, 07 Dec 2020 17:17:49 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= marcbradshaw.net; h=mime-version:message-id:in-reply-to :references:date:from:to:subject:content-type; s=fm2; bh=4ZEzN2L pwSpoTQ+mVmwERYlGKEggagCF1hQDnpy+gnQ=; b=Yu5B5Ixkv3KUo2jiFbiY9bi 04CFeZlNipQzF6o1XSD3i7nnUyQmtl1PVSSUGAz1L7JL63DVZFGGBVhipuqu2MTr m1AB0mY6l4lFuENlf7BVf2mJpXD9YHypOEukZSsLheM0u4DxoxL7NK1rbUlnHrtV 1XsOyEpIK6PNeYhBOuOuWc0IDcGbWdN2DeQC1adsz+iBojlZJ7TmRj0u45CGA2Ya SqlZheIsq0/1SDer7VGRIKEf1l8chaAEsda3oybP+I6AOsMf1DP5+OELGupVcMFl TgMxdC4M2+LHQ9/Ik/vYBIyBvnasuVZ6AsAsrEz08tlR3DqVXC9IMfzg0YiuMOw= = DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=4ZEzN2 LpwSpoTQ+mVmwERYlGKEggagCF1hQDnpy+gnQ=; b=p40Y3EnMGLnrXHxTF1s4ED 0uVRCY6TpK5smVEw+t5ckXOsMCx8+gZWdeOYKBep4UVXYcudZKC9W/2e6MhUayez 9xIxpa1Z8tWsjPA9G9M9XVQGNgnaflFvq7+LPFo8dzVFOqsxC79ga8lsPIVdXuVQ 4OXdMkmVuRBIdpx/jdBORdeR98Ua4JqJlPZhlWUN4kpfzDaWGkMlG7e5Adx1LwEY SlDe77/YNywmpOOAE0dbrmUdeeidL2XFrDHHo4rx11HVVYwYvhtq4YaWOHU8hVvC M+M0Bx1sDqIKfvJVCBfjDZkclEKMDtkNYPKyHwmJuY63LaA44UteoeBk9+UHlwow == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrudejgedgudehlecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefofgggkfgjfhffhffvufgtsegrtderreerredtnecuhfhrohhmpedfofgr rhgtuceurhgrughshhgrfidfuceomhgrrhgtsehmrghrtggsrhgrughshhgrfidrnhgvth eqnecuggftrfgrthhtvghrnhepvdetveejhfejtdehvedttefftddtffeiveffueevhefg teevtedvudeikedtiedvnecuffhomhgrihhnpeiffedrohhrghdpughmrghrtgdrohhrgh dpihgvthhfrdhorhhgpdhmrghrtggsrhgrughshhgrfidrnhgvthdpthifihhtthgvrhdr tghomhenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpe hmrghrtgesmhgrrhgtsghrrggushhhrgifrdhnvght X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 9CDAE20126; Mon, 7 Dec 2020 17:17:48 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-622-g4a97c0b-fm-20201115.001-g4a97c0b3 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Tue, 08 Dec 2020 09:17:16 +1100 From: "Marc Bradshaw" To: "DMARC IETF" Content-Type: multipart/alternative; boundary=cf268155a51c456b84a57e35dd933faf Archived-At: Subject: Re: [dmarc-ietf] Discussion - ARC/Extensible Reporting (Ticket #56) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 07 Dec 2020 22:17:54 -0000 --cf268155a51c456b84a57e35dd933faf Content-Type: text/plain There is value in including these in one report, especially where the extended property being reported on influences how DMARC is evaluated. Using ARC as the example, when a p=reject policy was overriden by the receiver because of an ARC evaluation, when that data is included in the report the indirect mail flow can be clearly seen, which would not be the case if ARC were included as a separate report. This could be included in an element, or could be included directly in the auth_results section of the report, based on an assumption that the things being reported SHOULD have an authentication results entry in processed mail. ... ... (as defined in arc standard) (as defined in foo standard) These would be defined in a registry with reference to each standard, and parsers would ignore any sections they did not understand. On Fri, 4 Dec 2020, at 6:43 AM, Alessandro Vesely wrote: > On Thu 03/Dec/2020 19:54:51 +0100 Brotman, Alex wrote: > > > >> -----Original Message----- > >> From: dmarc On Behalf Of Alessandro Vesely > >> Sent: Thursday, December 3, 2020 6:24 AM > >> To: dmarc@ietf.org > >> Subject: Re: [dmarc-ietf] Discussion - ARC/Extensible Reporting (Ticket #56) > >> > >> On Wed 02/Dec/2020 20:46:54 +0100 Brotman, Alex wrote: > >>> > >>> While this ticket/enhancement specifically mentions ARC, I could > >>> perhaps see the usefulness in other places. It seems like it would be > >>> more beneficial to create a method by which other documents could > >>> provide XML- based "extensions" to the report. This would allow > >>> mechanisms relying on DMARC to independently define their reporting > >>> schema to be included in DMARC aggregate reports. Alternately, we could > >>> focus specifically on ARC, and work to include that in the base XML. > >>> This means that any later reporting requirements could again require > >>> changes to the core drafts.>>> > >> > >> > >> Another possibility is for ARC to define its own report format. Hijacking > >> rua= targets to send a different kind of report should be allowed. > >> Otherwise, we could define a new tag, e.g. rue= (e for Extension).>> > >> In either case, as we're introduce variations in aggregate report content, > >> we have to devise a method for determining what version/kind of report is > >> attached to a given message.>> > > > > We could add an element called "", and we allow ARC or whatever > > it may be to exist under that element. The Aggregate Reporting document > > needs to specify that any extensions are expected to be proper XML, and if > > there are no extensions, an empty element is sufficient. We could create a > > bit more structure as a requirement if we wanted:> > > > > > > ... (as defined in referenced standard) > > > > > > > > If a report parser doesn't know what ARC is (or any of the extensions), it could skip the processing. I do understand this means that element may break existing parsers, even when empty, though, I expect many of the things we're proposing may fracture the expected XML. > > > We can do a better job at producing aggregate reports with an automatically verifiable content. For example, prepending stuff like this: > > > xmlns:dmarc="http://dmarc.org/dmarc-xml/0.1" > xs:schemaLocation="http://dmarc.org/dmarc-xml/0.1 rua.xsd"> > > ... > > (Perhaps something better than "http://dmarc.org/dmarc-xml/0.1" for the version) > > But then, would the imply dmarc-xml grammar should be upgraded every time ARC (or whatever) is upgraded? > > Separate reports sounds simpler. > > > Best > Ale > -- > > > > > > > > > > > > > > > > > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > -- Marc Bradshaw marcbradshaw.net | @marcbradshaw --cf268155a51c456b84a57e35dd933faf Content-Type: text/html Content-Transfer-Encoding: quoted-printable

=
There is value in including these in one report, especially where t= he extended property being reported on influences how DMARC is evaluated= .

Using ARC as the example, when a p=3Dreje= ct policy was overriden by the receiver because of an ARC evaluation, wh= en that data is included in the report the indirect mail flow can be cle= arly seen, which would not be the case if ARC were included as a separat= e report.

This could be included in an <= extension> element, or could be included directly in the auth_results= section of the report, based on an assumption that the things being rep= orted SHOULD have an authentication results entry in processed mail.
=

<auth_results>
<dkim>...</dkim><= span class=3D"font" style=3D"font-family:menlo, consolas, monospace, san= s-serif;">
<spf>...</spf>
<arc> (as defined = in arc standard) </arc>
<foo> (as defined in foo standard) </foo>
</auth_results>
=

These would be defined in a registry with refe= rence to each standard, and parsers would ignore any sections they did n= ot understand.

On Fri, 4 Dec 2020, at 6:43 = AM, Alessandro Vesely wrote:
On Thu 03/Dec/2020 19:54:51 +0100 Brotman, Alex wrote:=
> 
>> -----Original Message--= ---
>> From: dmarc <dmarc-bounces@ietf.org> On Behalf Of Alessandro Vese= ly
>> Sent: Thursday, December 3, 2020 6:24 AM
>> Subject: Re: [dmarc-ietf] Discussion - AR= C/Extensible Reporting (Ticket #56)
>>
>> On Wed 02/Dec/2020 20:46:54 +0100 Brotman, Alex wrote:
>>>
>>> While this ticket/enhance= ment specifically mentions ARC, I could
>>> perha= ps see the usefulness in other places.  It seems like it would be
>>> more beneficial to create a method by which ot= her documents could
>>> provide XML- based "exten= sions" to the report.  This would allow
>>> = mechanisms relying on DMARC to independently define their reporting
<= /div>
>>> schema to be included in DMARC aggregate reports.=   Alternately, we could
>>> focus specifical= ly on ARC, and work to include that in the base XML.
>&= gt;> This means that any later reporting requirements could again req= uire
>>> changes to the core drafts.>>><= br>
>>
>>
>> Ano= ther possibility is for ARC to define its own report format.  Hijac= king
>> rua=3D targets to send a different kind of r= eport should be allowed.
>> Otherwise, we could defi= ne a new tag, e.g. rue=3D (e for Extension).>>
>&= gt; In either case, as we're introduce variations in aggregate report co= ntent,
>> we have to devise a method for determining= what version/kind of report is 
>> attached to= a given message.>>
> 
> We= could add an element called "<extensions>", and we allow ARC or w= hatever
> it may be to exist under that element.  = The Aggregate Reporting document
> needs to specify tha= t any extensions are expected to be proper XML, and if
>= ; there are no extensions, an empty element is sufficient.  We coul= d create a
> bit more structure as a requirement if we = wanted:> 
> <extensions>
&g= t;    <extension name=3D"arc" standard=3D"ARC_DMARC_RE= PORTING_EXTENSION_DEFINITION">
>   &n= bsp;  ... (as defined in referenced standard)
>&nb= sp;   </extension>
> </extensions>= ;
> 
> If a report parser doesn't= know what ARC is (or any of the extensions), it could skip the processi= ng.  I do understand this means that <extensions> element may= break existing parsers, even when empty, though, I expect many of the t= hings we're proposing may fracture the expected XML.

<= /div>

We can do a better job at producing aggregate r= eports with an automatically verifiable content.  For example, prep= ending stuff like this:

<?xml version=3D= "1.0" encoding=3D"UTF-8"?>
<dmarc:feedback xmlns:xs=3D= "http://www.w3.org= /2001/XMLSchema-instance"
xmlns:dmarc=3D"http://dmarc.org/dmarc-xml/0.1"
xs:schemaLocation=3D"= http://dmarc.org/dmarc-xml/0.1 rua.xsd">
<report= _metadata>
        .= ..

(Perhaps something better than "http://dmarc.org/dmarc-xml/0.1" for= the version)

But then, would the <exten= sions> imply dmarc-xml grammar should be upgraded every time ARC (or = whatever) is upgraded?

Separate reports sou= nds simpler.


Best
<= div>Ale
-- 
















_______________________________________________
dmarc mailing list
<= div>

--

<= div class=3D"signature">  Marc Bradshaw
  marcbradshaw.net= | @marcbradshaw


--cf268155a51c456b84a57e35dd933faf-- From nobody Mon Dec 7 14:20: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 D0DA93A0B9C for ; Mon, 7 Dec 2020 14:20:14 -0800 (PST) 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 GYkCnpeRJu7O for ; Mon, 7 Dec 2020 14:20:13 -0800 (PST) Received: from mail-il1-x12e.google.com (mail-il1-x12e.google.com [IPv6:2607:f8b0:4864:20::12e]) (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 3F3443A0B92 for ; Mon, 7 Dec 2020 14:20:13 -0800 (PST) Received: by mail-il1-x12e.google.com with SMTP id x15so13779805ilq.1 for ; Mon, 07 Dec 2020 14:20:13 -0800 (PST) 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; bh=EOXscp35qB4bhNvfJY9bvTkCKpchv60eipLW2EvSrjQ=; b=cy+xv6cD6+8vvIFO6P2mqdrj82Xucu92NydO0ZYCggH+SGdPTdLZUmyz/ieiwSPunh jU76WMBuC+3f7W98jRB9tuGu5oHEt5u0VRysSJUr4ipBUxVlC1WemS7NxTy6DfkaPL3X nmlSoE1oCwwI9tEpm9KAfRhHb059IEkWu87C8= 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=EOXscp35qB4bhNvfJY9bvTkCKpchv60eipLW2EvSrjQ=; b=g4FkGC9iqat9mU8z+q3rsctPrneDLWtQNBxj2hSyjh7qMpdNkfvofDOarqFGDCFwyt GxoyIUnLA0xzlUI4Ouaw3B3KMYKCelMBp2+NYgGybRIUDtFS9ius4IzQq1Aeoqf9Sn7C pEH/9mFiSBl3CiEawVM2CEveQS0rp1prp7XFdw1Wsu8VJG9LwbE3qHTpQ+f/kyLNqT9F //R2DII06jNj6Wg/QFfgiXSJPohXRmCdRZLNYnjVnJIGVe6fvLiOBV53dmrrsHlOmlqL r5wcapkPKTQTrryS3RncB+I3VinfRboLX+Fer7lep5s8RdDgJ8Llj42GXUhRjvx8+c8f DRzg== X-Gm-Message-State: AOAM533px6v/3J3QMlkEHD8Li+Q5Big72XuMdzfsp/VfNq84p4tJwDZd lhnDfQi+K02mOwbT1HivgUSNUrJocgi3eH24DK+PIT8M+26LEw== X-Google-Smtp-Source: ABdhPJzY9YAUTqlHIfFlwNANpfGJ2E7AjmaushRXsMaiRLKu6SbjrjApIsXP63ngQiZlY51zSqVbViOOtmOc7YTIM0c= X-Received: by 2002:a92:9509:: with SMTP id y9mr23493216ilh.103.1607379612296; Mon, 07 Dec 2020 14:20:12 -0800 (PST) MIME-Version: 1.0 References: <20201205231059.2BA23290EDCD@ary.qy> <7ae42764-176d-11a8-e084-b10b6f676944@mtcc.com> <8142f18c-ac79-1f94-97d1-2704f0b4ceb6@mtcc.com> In-Reply-To: From: "Kurt Andersen (b)" Date: Mon, 7 Dec 2020 14:19:46 -0800 Message-ID: To: Douglas Foster , "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="000000000000cf82f805b5e73a01" Archived-At: Subject: Re: [dmarc-ietf] ARC vs reject X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 07 Dec 2020 22:20:15 -0000 --000000000000cf82f805b5e73a01 Content-Type: text/plain; charset="UTF-8" On Sat, Dec 5, 2020 at 5:21 PM Douglas Foster < dougfoster.emailstandards@gmail.com> wrote: > ...much of this is about AOL in particular, and the currently available > information suggests that AOL is not on board with ARC. > I would point you to https://tools.ietf.org/html/draft-ietf-dmarc-arc-protocol-22#section-12.2 (note that per normal IETF procedure, section 12 is removed in the editorial conversion from an I-D to an RFC). --Kurt --000000000000cf82f805b5e73a01 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sat, Dec 5, 2020 at 5:21 PM Douglas Fo= ster <dougfoster.= emailstandards@gmail.com> wrote:
..= .much of this is about AOL in particular, and the currently available infor= mation suggests that AOL is not on board with ARC.
=

I would point you to=C2=A0https://tools.ietf= .org/html/draft-ietf-dmarc-arc-protocol-22#section-12.2 (note that per = normal IETF procedure, section 12 is removed in the editorial conversion fr= om an I-D to an RFC).

--Kurt=C2=A0
--000000000000cf82f805b5e73a01-- From nobody Mon Dec 7 14:25: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 3474F3A0BA4 for ; Mon, 7 Dec 2020 14:25:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.118 X-Spam-Level: X-Spam-Status: No, score=-2.118 tagged_above=-999 required=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_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, SPOOF_COM2OTH=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=marcbradshaw.net header.b=XuoiYvmS; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=MV6R3ZlA Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bO2a8JYR5IqE for ; Mon, 7 Dec 2020 14:25:49 -0800 (PST) Received: from wout1-smtp.messagingengine.com (wout1-smtp.messagingengine.com [64.147.123.24]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 342343A0B85 for ; Mon, 7 Dec 2020 14:25:49 -0800 (PST) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.west.internal (Postfix) with ESMTP id BBD0C153D for ; Mon, 7 Dec 2020 17:25:47 -0500 (EST) Received: from imap10 ([10.202.2.60]) by compute3.internal (MEProxy); Mon, 07 Dec 2020 17:25:47 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= marcbradshaw.net; h=mime-version:message-id:in-reply-to :references:date:from:to:subject:content-type; s=fm2; bh=+SfAfan q/dPh/WQx5bze8a9H8PCw33Xko33BJUigSU4=; b=XuoiYvmS0pTmR7Mx8eMKLtn G4RCVMeOqmOie3UoKGF8of7+WEMHBoPV8hMFQzIIsEoxFfjMYx07Ti84xWobSfRH GV+bCe/J/FKdheEFVrgTxuIAOzJPF2gVo2KzY0825kdnMIH+gXgzEY3c/CC9q/tX PMU4PM9IKI0+cDhlK6lmf9yOvpB0W+eD7ySnsPj4FSxam4QNEjXtWMKeaCTXaxUj Qi/VebjxLQU3jnQSqLU7XYjkGqHuL7LqZIsH5u58sE4g8toYJEhLUMQdPxnLh6bo 1swm9fMClwy79PJxf8qirZmz2cEwSzdGi/sTIZvXRDManC9UiPcrUkP2rRA6jUA= = DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=+SfAfa nq/dPh/WQx5bze8a9H8PCw33Xko33BJUigSU4=; b=MV6R3ZlAuuclrqKMWbJzPI FWvALSscSYDIhTbgcSaeABxYeAqAQKy/EoOb4gNCpGFP8tFfmHZhTsG7DOCzgPM3 vuWj/l3/DazMIKyHKK3wyq4ohvutA7In4y1DK0YuHbrPaeY0LOSMq+0ec4lBykQo rUSVqGHYQv8YD3RE2Y8FqaYrRgOzMOSE47RdUsRtTn4mTnBcadK94cTVZGnOqSSG OjTKIcDD5dOBAL5Xg4T9o9uO5YYcoikAIEuu2Gybg+K/oUjs5u3Q//mCaCBZvg8C 6RN5frKVU5eE228RyHM3FIK/BvSHBPVRDORKkzl+sKfF5hyQt1GIgHNbb+G7XMOw == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrudejgedgudeitdcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enogfuuhhsphgvtghtkfhmghffohhmrghinhculdeftddmnecujfgurhepofgfggfkjghf fffhvffutgesrgdtreerreerjeenucfhrhhomhepfdforghrtgcuuehrrggushhhrgiffd cuoehmrghrtgesmhgrrhgtsghrrggushhhrgifrdhnvghtqeenucggtffrrghtthgvrhhn pefhtdevheetgfevgedvudekjeejieeuvdeftddvueevvdegheeuudevtddtjedvvdenuc ffohhmrghinhepvgigrghmphhlvgdrnhgvthdpihgvthhfrdhorhhgpdhmrghrtggsrhgr ughshhgrfidrnhgvthdpthifihhtthgvrhdrtghomhenucevlhhushhtvghrufhiiigvpe dtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmrghrtgesmhgrrhgtsghrrggushhhrgif rdhnvght X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id A311B20126; Mon, 7 Dec 2020 17:25:46 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-622-g4a97c0b-fm-20201115.001-g4a97c0b3 Mime-Version: 1.0 Message-Id: <0359b009-5b18-46f8-85a5-959ad337dd49@beta.fastmail.com> In-Reply-To: References: Date: Tue, 08 Dec 2020 09:25:10 +1100 From: "Marc Bradshaw" To: "DMARC IETF" Content-Type: multipart/alternative; boundary=8a1f2393ae514dfba4b0d41fa2cc6031 Archived-At: Subject: Re: [dmarc-ietf] =?utf-8?q?Discussion=3A_Removal_of_validation_for_e?= =?utf-8?q?xternal_destinations_=28Ticket_=2376=29?= X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2020 22:25:51 -0000 --8a1f2393ae514dfba4b0d41fa2cc6031 Content-Type: text/plain Removing this opens up the potential for abuse, I don't see the value in removing it. On Sun, 6 Dec 2020, at 11:06 PM, Alessandro Vesely wrote: > On Sat 05/Dec/2020 14:51:52 +0100 Brotman, Alex wrote: > > > > There's currently a ticket that suggests that the requirement for external validation be removed. Today, if example.com has an RUA that points at example.net, the latter must create a record as such: > > > > example.com._report._dmarc.example.net TXT "v=DMARC1" > > > Actually, the record can also be: > > example.com._report._dmarc.example.net TXT "v=DMARC1; rua=updated-address@example.net" > > or even, considering a parallel thread: > > example.com._report._dmarc.example.net TXT "v=DMARC1; rua=report@example.net, /https://www.example.net/report/" > > > That way, external services have the ability to control or suspend their service. I think this is an essential requirement. Let's keep it. > > > > The original thought was that a bad actor could overwhelm a target with unrequested reports. It seems in reality, most report generators only send once per day. > > > Once-per-day has to be amended. See ticket #71. > > > > Additionally, there appear to be some generators who ignore the absence of these records. > > > Aggregate reports are often tagged as spam anyway, but when sent in violation of the spec such tagging is certainly deserved. > > > > https://tools.ietf.org/html/rfc7489#section-7.1 > > > Why don't you refer to either of the drafts we're editing: > https://tools.ietf.org/html/draft-ietf-dmarc-aggregate-reporting-00#section-2.1 > https://tools.ietf.org/html/draft-ietf-dmarc-failure-reporting-00#section-3.2 > > BTW, this duplication is worth yet another ticket. > > > Best > Ale > -- > > > > > > > > > > > > > > > > > > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > -- Marc Bradshaw marcbradshaw.net | @marcbradshaw --8a1f2393ae514dfba4b0d41fa2cc6031 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
Removing this o= pens up the potential for abuse, I don't see the value in removing it.

On Sun, 6 Dec 2020, at 11:06 PM, Alessandro = Vesely wrote:
On Sat 05/Dec/2020 14:51:52 +0100 Brotman, Alex wrote:
= > 
> There's currently a ticket that suggests t= hat the requirement for external validation be removed.  Today, if = example.com has an RUA that points at example.net, the latter must creat= e a record as such:
> 
> example.= com._report._dmarc.example.net TXT "v=3DDMARC1"

=

Actually, the record can also be:

=
example.com._report._dmarc.example.net TXT "v=3DDMARC1; rua=3D= updated-address@example.n= et"

or even, considering a parallel thr= ead:

example.com._report._dmarc.example.net= TXT "v=3DDMARC1; rua=3Dreport@exa= mple.net, /https://www.e= xample.net/report/"


That= way, external services have the ability to control or suspend  the= ir service.  I think this is an essential requirement.  Let's = keep it.


> The original t= hought was that a bad actor could overwhelm a target with unrequested re= ports.  It seems in reality, most report generators only send once = per day.


Once-per-day has to= be amended.  See ticket #71.


> Additionally, there appear to be some generators who ignore = the absence of these records.


Aggregate reports are often tagged as spam anyway, but when sent in vi= olation of the spec such tagging is certainly deserved.



Why don't you refer to= either of the drafts we're editing:

<= /div>
BTW, this duplication is worth yet another ticket.


Best
Ale
--=  












=




_______________________________________________
dmarc m= ailing list

<= /div>

--
<= table>
  Marc Bradshaw
&n= bsp; marcbradshaw.net |&nb= sp;@marcbradshaw


--8a1f2393ae514dfba4b0d41fa2cc6031-- From nobody Mon Dec 7 14:27: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 44D3A3A0C5E for ; Mon, 7 Dec 2020 14:27:39 -0800 (PST) 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 TSfoW4kDkN9G for ; Mon, 7 Dec 2020 14:27:38 -0800 (PST) Received: from mail-io1-xd2d.google.com (mail-io1-xd2d.google.com [IPv6:2607:f8b0:4864:20::d2d]) (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 D1F173A0C52 for ; Mon, 7 Dec 2020 14:27:37 -0800 (PST) Received: by mail-io1-xd2d.google.com with SMTP id 81so14972899ioc.13 for ; Mon, 07 Dec 2020 14:27:37 -0800 (PST) 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=cz+TCQjjth6KQ2Zalc5htPFhx9+Jf7e6EF66VdwS9P0=; b=fsKYxRWM9NJqDgL8ugNgP3Z/0WR+hstPT1rJfMuxxmCpvOCrF1l/6Gw6uitE9ue6gc U1PW91t0lppKPHsfBr6nQxy8Mxc/fTtXQZgUtgsbvuU2i+1E6eTTsf/7kRlwXsHcCMST YOJQjuliOOWvZvkndiNF9O1OJOW6ajMNv4+3A= 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=cz+TCQjjth6KQ2Zalc5htPFhx9+Jf7e6EF66VdwS9P0=; b=HmYyI1rpyO+E+M0i/MtJ4hdy1y5TAKM1Re79MieSJfC+abR+9uT9A1+HIOY6A3YQDr e+qJjpzTSH+Xp6gIrEInrMayjNvlqaj797cCC2Flh7D+BxqGJBxR6z97sRWHIA31qMK+ 4cOq5L0ofgxErHHvyL2KmKRf9K8tFYecg6bYCbC34xhNBXXe6nO+hAa2P0SDuHc2dpXO GGK94QbujtdkzFsd+boF9jrlowJgtmweezRVeYDMXxJ4LnaiDCgGp/D1mJ+L/krw8Sul //DTWUy5E0LaO4BXDwXuQNkLdTl5i952Kp6f5f35b4zSBxF8W7o/CEzRTdRYrxwOSDYK cQ1w== X-Gm-Message-State: AOAM533IkDl7niXAOgh2WWuD4mwCuM6dTuuPqIokygI+BPVPPWh+X9f4 BmysQMEwzaL88D2UmA8x59YPacwWbCKED/vVS9A0cQ== X-Google-Smtp-Source: ABdhPJyUpgCmCHd1tjwvyncJ5ELEV9ZxkL5MjkTEvBhXM+mECIVwKh1ujZ46+to9fVFFzppYzfzhuiKvtR+CCgp98f8= X-Received: by 2002:a5d:8793:: with SMTP id f19mr21905972ion.106.1607380057042; Mon, 07 Dec 2020 14:27:37 -0800 (PST) MIME-Version: 1.0 References: <20201205210351.DB78E2904420@ary.qy> <28759E60-3A00-4D25-9490-34495B96EE10@bluepopcorn.net> <9c23d850-4164-1320-1c25-40554c1f64b@taugh.com> In-Reply-To: From: "Kurt Andersen (b)" Date: Mon, 7 Dec 2020 14:27:11 -0800 Message-ID: To: Douglas Foster Cc: "dmarc@ietf.org" , dmarc-chairs@ietf.ord Content-Type: multipart/alternative; boundary="00000000000051c78d05b5e75577" Archived-At: Subject: Re: [dmarc-ietf] ARC vs reject X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 07 Dec 2020 22:27:47 -0000 --00000000000051c78d05b5e75577 Content-Type: text/plain; charset="UTF-8" On Sun, Dec 6, 2020 at 10:46 AM Douglas Foster < dougfoster.emailstandards@gmail.com> wrote: > > I ask the chairs to formally endorse development of an alternative to ARC > as an additional approach to the mailing list problem... > So you are asking the WG to go back to our second milestone and put the current work on milestone 3 on hold? --Kurt --00000000000051c78d05b5e75577 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sun, Dec 6, 2020 at 10:46 AM Douglas F= oster <dougfoster= .emailstandards@gmail.com> wrote:
<= br>
I ask the chairs to formally endorse development of an altern= ative to ARC as an additional approach to the mailing list problem...
=

So you are asking the WG to go back = to our second milestone and put the current work on milestone 3 on hold?=C2= =A0

--Kurt=C2=A0
--00000000000051c78d05b5e75577-- From nobody Mon Dec 7 14:49: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 732643A0C00 for ; Mon, 7 Dec 2020 14:49:04 -0800 (PST) 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 zsrAZSQieI6k for ; Mon, 7 Dec 2020 14:49:01 -0800 (PST) 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 AD2DE3A0B75 for ; Mon, 7 Dec 2020 14:49:01 -0800 (PST) Received: by mail-vs1-xe2c.google.com with SMTP id r24so2684265vsg.10 for ; Mon, 07 Dec 2020 14:49:01 -0800 (PST) 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=quANhAPwB/vki/kkOImSz7cvAtckO+tp/6BJdlAxD3A=; b=I5VFAgVU+a7dP6nWacp6dh7VxgB4HELGfA//yQJs2DhPSFghzwU9CT9Lg8LtwH7ArD tOvwXMvqJHr9QRnlApIT1Aaq4dd+wifWarRanxN6TagOx4tTMR8ojH4QX5P9/JkV6CtB weEnNyjGprw68Dj2mhkdJrtUb3XXjbDUGW/+RwD2xfXgPrjlwvV72L/n9T2Ga/DwuHrU xoJss9BJA4trEUuSZijApA1Y+BxflMvLP4W0xNa4mQ5RdK11mJzhhtU6U/gmA45rz7VN S5xSW3SIiJLNaV3tdauxK6bVzVXJoI/ws5SZVJ3YxPATJQLfYl2jeldDM/ud8k8BALYy 91xQ== 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=quANhAPwB/vki/kkOImSz7cvAtckO+tp/6BJdlAxD3A=; b=uLk1ggg4rNjP55Wmc8uKirdn6D49rjW+0zWxvhUxLzXP6KTbsffCcqhuCqEbTPLy4v xqd3DCoCloILFv5IS2VKxiGmExOFxyo+8PDbf3y4wUh+SLdmqrA74C7ZfIJv7KZsOFFc +bIeytmJjjKvl9DYuCM5Za8ZX056wVQuwiTMQde0lfRMBUWCW+PHZ5FhvSEs2SWusgZt 7DEm8KG64+UXL114gEEEIPmga2nVC10IAfn6mOTgw4hCoOA2Tb+iQq1Ua20Gq9JujS3y CeIal8EHBGNYSD92FdpUmcr89exO+F3NWINikx9Dwcq2kquZO9MQ8sJipVVm/fMJAa/a Ti6g== X-Gm-Message-State: AOAM530jAfx1jDhKmkTgsFsYahesW0eyOBGVP6faXyfXNfHptk76c+gj 5MnY9XnmKJXPtkWdIKwdH9fRlCUUN+8ldLrWJoh5vm5LMsg= X-Google-Smtp-Source: ABdhPJyZiSV/BmGI/bBaFHk/swL0Fq4tGnnqM5PuUDMhBssE8F5Us/lzMFdixEoTh+oFr//4RxuZmQH+HW8Fxoryn4s= X-Received: by 2002:a05:6102:2427:: with SMTP id l7mr12146738vsi.43.1607381340060; Mon, 07 Dec 2020 14:49:00 -0800 (PST) MIME-Version: 1.0 References: <20201205210351.DB78E2904420@ary.qy> <28759E60-3A00-4D25-9490-34495B96EE10@bluepopcorn.net> <9c23d850-4164-1320-1c25-40554c1f64b@taugh.com> In-Reply-To: From: Seth Blank Date: Mon, 7 Dec 2020 14:48:48 -0800 Message-ID: To: IETF DMARC WG Cc: Douglas Foster , dmarc-chairs@ietf.ord, Kurt Andersen Content-Type: multipart/alternative; boundary="000000000000cb132c05b5e7a156" Archived-At: Subject: Re: [dmarc-ietf] ARC vs reject X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 07 Dec 2020 22:49:05 -0000 --000000000000cb132c05b5e7a156 Content-Type: text/plain; charset="UTF-8" On Mon, Dec 7, 2020 at 2:28 PM Kurt Andersen (b) wrote: > On Sun, Dec 6, 2020 at 10:46 AM Douglas Foster < > dougfoster.emailstandards@gmail.com> wrote: > >> >> I ask the chairs to formally endorse development of an alternative to ARC >> as an additional approach to the mailing list problem... >> > > So you are asking the WG to go back to our second milestone and put the > current work on milestone 3 on hold? > This thread is now extremely off topic. As Kurt rightly mentioned, addressing indirect mailflow was a WG milestone that has been completed. We are now in another phase of work -- driving DMARC to a standards track document -- which has open tickets and editors waiting on WG consensus. This conversation around indirect mail streams, which the chairs had hoped would run its own course, is now counter productive. The Chairs are officially calling discussion of indirect mail flows OFF TOPIC until all open bis tickets in trac are resolved. After all tickets are resolved, but prior to WGLC on the bis documents, we will return to a discussion of indirect mail flow and where ARC stands. For now, move on to open tickets. Seth, for the Chairs -- *Seth Blank* | VP, Standards and New Technologies *e:* seth@valimail.com *p:* 415.273.8818 This email and all data transmitted with it contains confidential and/or proprietary information intended solely for the use of individual(s) authorized to receive it. If you are not an intended and authorized recipient you are hereby notified of any use, disclosure, copying or distribution of the information included in this transmission is prohibited and may be unlawful. Please immediately notify the sender by replying to this email and then delete it from your system. --000000000000cb132c05b5e7a156 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Dec 7, 2020 at 2:28 PM Kurt Ander= sen (b) <kboth@drkurt.com> wr= ote:
On Sun, Dec 6, 2020 at 10= :46 AM Douglas Foster <dougfoster.emailstandards@gmail.com> wrote:<= br>

I ask the chairs to formall= y endorse development of an alternative to ARC as an additional approach to= the mailing list problem...

So= you are asking the WG to go back to our second milestone and put the curre= nt work on milestone 3 on hold?=C2=A0
This thread is now extremely off topic.

As Kurt rightly mentioned, addressing indirect mailflow was a WG milesto= ne that has been completed. We are now in another phase of work -- driving = DMARC to a standards track document -- which has open tickets and editors w= aiting on WG consensus. This conversation around indirect mail streams, whi= ch the chairs had hoped would run its own course, is now counter productive= .

The Chairs are officially calling discussion of = indirect mail flows OFF TOPIC until all open bis tickets in trac are resolv= ed. After all tickets are resolved, but prior to WGLC on the bis documents,= we will return to a discussion of indirect mail flow and where ARC stands.= For now, move on to open tickets.

Seth, for t= he Chairs

--

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


This email and all data transmitted= with it contains confidential and/or proprietary information intended sole= ly 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, disc= losure, copying or distribution of the information included in this transmi= ssion is prohibited and may be unlawful. Please immediately notify the send= er by replying to this email and then delete it from your system.

--000000000000cb132c05b5e7a156-- From nobody Mon Dec 7 15:43: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 79ECC3A0CB8 for ; Mon, 7 Dec 2020 15:43:45 -0800 (PST) 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 AuT2EbcCKb5z for ; Mon, 7 Dec 2020 15:43:44 -0800 (PST) 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 0A6923A0CB5 for ; Mon, 7 Dec 2020 15:43:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bluepopcorn.net; s=supersize; h=Content-Transfer-Encoding:Content-Type: MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From:Sender :Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=hYYDEUtMmhb11zuSiymMm6wm93UxSVD4RcmCseGWr+w=; b=HyrgcBAZyJ8iG2/UKX4ISMTCYL pDwMb6AdU9tfrm3KYruUuf/0eAwspPX1JHHrrCRjFBGYK/hhC26x8HCK6G9Ppqs9lCsglEkVFvA9+ XwpuajHL+LND1R4hBak39PoNoCTbE1nWStQkGsHPqwo8FfQrxmCff+5/TNWbMuz2wYfY=; Received: from [2601:647:4400:1261:9511:8ebf:831d:3a40] (helo=[10.10.20.144]) by v2.bluepopcorn.net with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kmQAP-0005vV-Hr; Mon, 07 Dec 2020 15:43:41 -0800 From: "Jim Fenton" To: "John Levine" Cc: dmarc@ietf.org, superuser@gmail.com Date: Mon, 07 Dec 2020 15:43:40 -0800 X-Mailer: MailMate (1.13.2r5673) Message-ID: <5EFCDAFF-26EF-4FC1-B7E2-E44CA66872BB@bluepopcorn.net> In-Reply-To: <20201207051846.CBEEE291CC3F@ary.qy> References: <20201207051846.CBEEE291CC3F@ary.qy> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] not ADSP, was is DMARC informational? X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 07 Dec 2020 23:43:46 -0000 On 6 Dec 2020, at 21:18, John Levine wrote: > In article > > you write: > >> As I recall, people took a run at trying ADSP and it was largely >> unsuccessful. I recall at least Yahoo, PayPal, and Google trying it >> but >> finding that it interfered with their employees' participation in >> lists, so >> they each invented new domains for their employees to use as separate >> from >> their operational public services. This basically led to its demise. IIRC, Yahoo! And Google had separate domains for their employees well before ADSP. Which makes sense, because you want to differentiate your employees from your customers. Although I’m not sure that matters here. > Among ADSP's shortcomings was that there was no way to test it other > than to turn it on and see how much damage it caused. The answer was > frequently a lot, so they turned it back off and that was that. > > DMARC certainly has its problems but the reporting is great. It makes > the surprises when you turn DMARC on a lot less, at least if your name > is not AOL or Yahoo. Agree, the reporting is great. But so much of the marketing/mandates I see around DMARC doesn’t tell domain owners to turn on reporting first to see what’s broken, it tells them to publish a DMARC p=reject policy because they have a security vulnerability if they don’t. If the guidance around DMARC was to publish a p=reject policy only “if it’s safe to do so” (meaning mostly for transactional domains), I’d be a lot happier with it. -Jim From nobody Mon Dec 7 16:45: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 A02B93A0CF8 for ; Mon, 7 Dec 2020 16:45:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.12 X-Spam-Level: X-Spam-Status: No, score=-2.12 tagged_above=-999 required=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.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=thedave.ca header.b=RiFQhhBM; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=r0SNvuXY Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rhibxikcBeHy for ; Mon, 7 Dec 2020 16:45:15 -0800 (PST) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 655163A0825 for ; Mon, 7 Dec 2020 16:45:15 -0800 (PST) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 949595C020B for ; Mon, 7 Dec 2020 19:45:14 -0500 (EST) Received: from imap9 ([10.202.2.59]) by compute4.internal (MEProxy); Mon, 07 Dec 2020 19:45:14 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thedave.ca; h= mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm1; bh=UQNR7kjyBQIa8DJWCfvTbLDapo7u6bd OHr382sf3PUE=; b=RiFQhhBM7omlONQah8m3m3895hV9Xsu8GRfnicY2IApSvOG dGKNBJSUzbixceYLt7KheFat4m3XlPBmwNJ8kqKFEA9yJEjFn2/KAChc/WfwwhKj xBk8timWGJqFfHKuXyHCzI1iASul59YXsztMWSnxwg8uE9KalP/P7GFp2NLwNnjG Uqm++riYRHubdYt6X6E0z4owL5x6eS/+QqJaCV/GywqMhMFkEvvuu8L5HdHuvH/x 4+QazD8X9tnZgLoG/hfbE6gIgYWMZb2gMQTQUhvfpv/Zhbe+3mRIFAyrwlVCYIy4 EMtHNH5YY5bCumgv8c9ATu8fl/POTdAuuSpLjtQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=UQNR7k jyBQIa8DJWCfvTbLDapo7u6bdOHr382sf3PUE=; b=r0SNvuXYK1Prvss0chVuwF Y/yjUlN8iUWC24E3y2s8bwBbGm/Ht0lK/jxOT/oT3BM0N4jMxsLQCSj9SwOrlmW1 Lv3Ho0gisQIOvhZHjyQNLliRNldHOCKtuHSQwBomPS2meDDw1fKZgzk0m1Ml6YNX iaJfXbKt9/MX9okP2IoGQIuWgRBP+DkxPJT3VNaiaDtsXEy2G7clkqf3/LRRGCoP 85zVujLuDMiguodF7Lcatt24ssHT+P/Xlj1K5AVQdiGEFTFQI9fPa7Ktx4XnxSMt rDce6J6nfZjRQiiGkqqJzZJEQ385sh+6c0f+i15dfPV5DKZ3L7BsX9BHIRM2mrEw == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrudejhedgvdehucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsehttd ertderredtnecuhfhrohhmpedfffgrvhgvucghrghrrhgvnhdfuceougifsehthhgvuggr vhgvrdgtrgeqnecuggftrfgrthhtvghrnhepjeeugfefudekgfevtdehvddvhfetueefke fhuedukeefgeekhefgtdduiedvgfejnecuvehluhhsthgvrhfuihiivgeptdenucfrrghr rghmpehmrghilhhfrhhomhepugifsehthhgvuggrvhgvrdgtrg X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 2EC061C0099; Mon, 7 Dec 2020 19:45:14 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-622-g4a97c0b-fm-20201115.001-g4a97c0b3 Mime-Version: 1.0 Message-Id: <7a992502-349c-45a0-ac2a-9ec33aa98035@www.fastmail.com> In-Reply-To: References: <20201207051846.CBEEE291CC3F@ary.qy> Date: Mon, 07 Dec 2020 17:44:54 -0700 From: "Dave Warren" To: dmarc@ietf.org Content-Type: text/plain Archived-At: Subject: Re: [dmarc-ietf] not ADSP, was is DMARC informational? X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 08 Dec 2020 00:45:17 -0000 On Sun, Dec 6, 2020, at 22:31, Michael Thomas wrote: > there are clearly many use cases where that isn't a problem -- like bank > transactional mail -- and ADSP was just fine for that. There were still surprises to be had here. I still, to this day, find mail direct from various senders that are wanted by the recipient but that fails SPF without forwarding (with a -all) or hits a dmarc=reject. I quarantine such for review and release to users as needed. Obviously lots is spam, or forwarding that broke SPF or whatever, but just as often it is a small piece of a big company doing something without fully understanding how modern email works. Oddly it is often security sensitive stuff, not crazy long ago it was Facebook password resets, often it is 2FA codes (which are probably going through a separate channel to get immediate delivery without risking backlog?), and other reasonably important things from parts of the company that I would expect to be at least moderately aware of the email security world. I agree that ADSP was theoretically fine for this type of use, but in practice, DMARC's feedback simplifies things a lot when a client complains their outbound mail isn't making it and we can quickly see what is being rejected. it is an imperfect world. From nobody Mon Dec 7 16:50: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 D3B653A0D29 for ; Mon, 7 Dec 2020 16:50:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.652 X-Spam-Level: X-Spam-Status: No, score=-1.652 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mtcc-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ysbfpvP2w500 for ; Mon, 7 Dec 2020 16:50:30 -0800 (PST) Received: from mail-pl1-x62d.google.com (mail-pl1-x62d.google.com [IPv6:2607:f8b0:4864:20::62d]) (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 C4C283A0D21 for ; Mon, 7 Dec 2020 16:50:30 -0800 (PST) Received: by mail-pl1-x62d.google.com with SMTP id y10so4602052plr.10 for ; Mon, 07 Dec 2020 16:50:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mtcc-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=pjNf1/UUTKDCgVzIUTsWrQkX7J1OJkT2vY7UMWNiQNo=; b=sqFVPuK9H15sBasoqA/TssSbYY3Z3RhoZI3V+Yi5HMq/EKsJuXu5xqVyOSKd2hBjav sN7m8N8xm8Sd/vPdxUBLYMpqcyV+AwfEQekie2gF1+bwVcev+t5Uu+vap42U/EG5GjB+ JcxD3DK3pjU4njJ07wjm0NNM9qSAvjTq+Fi2uWkZvORilAxJ1i/dmdvazazPsXSZ2yi1 cubjlMvcQFubBRMgxbS8KBjEKxjV+M2w1vKKOWGT5BEQg9cqnAvTXkgIc9RTOYe+FYGW exjtUqd8G5iVe5znews65vLIdeVxRGgJ2TY0ww9je69HL5f5EeI3K2Hmobg6lRYKaSic st4g== 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=pjNf1/UUTKDCgVzIUTsWrQkX7J1OJkT2vY7UMWNiQNo=; b=ChIMNvEXctXOKDZWis3pFjN4CbZ+wXrEGn5jZTc1kjca0KCHswQjZaFECOyeeW5Jxv QAwMrLuDLe5eZqG/6XCVx2kKDQPzQcpkhsXPPZ5LkZnVHVMg/IBf/WAiTVxh0ul36g1E bIU0r2QBzw25Xi23p8Eo1U+ZEuHEkQU8dIDQ6D2rDjy5+CNUdmV4I/n0yqdzxDd/gNIo DwQwwZqLTluW/GslYwvo9wiBXEsZNNd8N+TB4F81sn+Khkv/IipCXA7NcnpoG/3p13lH VNYlLfkHu8puHC7SGmaISD5n88N5ZwNEOri8OzbtH2+Vtxqr80LprbbsdvUD5LB86fta AeSQ== X-Gm-Message-State: AOAM5321MThvn+L6qoJS0l8m17tHpi3EQtjlz3hQ+0FDkQnmrdOsbN3t PtCk/zfylzSPye6V+A0IIuwiPN9LATnKkw== X-Google-Smtp-Source: ABdhPJwWtGyo6n849XZsWVyw5uK+jMjEA6631K74T1L8JPuLVPq4OTAFG8IzPjIVvd/62Bm0qqJeEw== X-Received: by 2002:a17:902:8498:b029:d8:e2a0:e4e7 with SMTP id c24-20020a1709028498b02900d8e2a0e4e7mr19077601plo.49.1607388629719; Mon, 07 Dec 2020 16:50:29 -0800 (PST) Received: from mike-mac.lan (107-182-41-154.volcanocom.com. [107.182.41.154]) by smtp.gmail.com with ESMTPSA id s189sm14922711pfb.60.2020.12.07.16.50.28 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 07 Dec 2020 16:50:28 -0800 (PST) To: dmarc@ietf.org References: <20201207051846.CBEEE291CC3F@ary.qy> <7a992502-349c-45a0-ac2a-9ec33aa98035@www.fastmail.com> From: Michael Thomas Message-ID: <347c3c91-476b-a2d1-57c7-a68435fbbf9e@mtcc.com> Date: Mon, 7 Dec 2020 16:50:27 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 MIME-Version: 1.0 In-Reply-To: <7a992502-349c-45a0-ac2a-9ec33aa98035@www.fastmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] not ADSP, was is DMARC informational? X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 08 Dec 2020 00:50:32 -0000 On 12/7/20 4:44 PM, Dave Warren wrote: > On Sun, Dec 6, 2020, at 22:31, Michael Thomas wrote: >> there are clearly many use cases where that isn't a problem -- like bank >> transactional mail -- and ADSP was just fine for that. > There were still surprises to be had here. I still, to this day, find mail direct from various senders that are wanted by the recipient but that fails SPF without forwarding (with a -all) or hits a dmarc=reject. I quarantine such for review and release to users as needed. > > Obviously lots is spam, or forwarding that broke SPF or whatever, but just as often it is a small piece of a big company doing something without fully understanding how modern email works. Oddly it is often security sensitive stuff, not crazy long ago it was Facebook password resets, often it is 2FA codes (which are probably going through a separate channel to get immediate delivery without risking backlog?), and other reasonably important things from parts of the company that I would expect to be at least moderately aware of the email security world. > > I agree that ADSP was theoretically fine for this type of use, but in practice, DMARC's feedback simplifies things a lot when a client complains their outbound mail isn't making it and we can quickly see what is being rejected. > > it is an imperfect world. I fear that DMARC's reporting only confirmed the obvious: this is hard. It gave numbers to anecdotes. That's really useful, don't get me wrong. Hopefully it can be used to suss out how to demarcate the long tail of don't care use cases. Mike From nobody Mon Dec 7 17:15:41 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60BCB3A0D45 for ; Mon, 7 Dec 2020 17:15:39 -0800 (PST) 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 McOTFVX3qPue for ; Mon, 7 Dec 2020 17:15:37 -0800 (PST) Received: from mail-oo1-xc36.google.com (mail-oo1-xc36.google.com [IPv6:2607:f8b0:4864:20::c36]) (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 85CF53A0D43 for ; Mon, 7 Dec 2020 17:15:37 -0800 (PST) Received: by mail-oo1-xc36.google.com with SMTP id q20so1913819oos.12 for ; Mon, 07 Dec 2020 17:15:37 -0800 (PST) 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=To8Fmv+LpeBLUbnsUQNDlxqrWuY17znVm7raNz1gpOw=; b=D9EjO4uzDr+hCHH0+mtAEh3dSUjVzrc35xFRbF1BRPHE3RTonr6IQefm/jGpwZ618l eT4PoSImD7zYzoEN3Zy0pbcrKumB+g0gAQTMJ/okPHfrDoUyzRx6z/3bcrabBp53d6yF Z+lNY4nPqvBk6ZJLKvCwtpNanh8MA4ye7AmdY8VVIz///yEzwOeCoCzp23a10xyxOIVZ zUULJTmmGNR5bwcoH5mgvSuZYgA+x95dOM+rVj42xrGbnx8E1z6OYWzGMMjb9Is5FNRh 8pTtzTvEq5hfql1MmrTbJHCHjG1sCvt6VO0qJFi4S6vAVr8ykCRAGZtWPcra1JazShUl 8YMA== 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=To8Fmv+LpeBLUbnsUQNDlxqrWuY17znVm7raNz1gpOw=; b=JpgMrowwpKYhL9vwCZP8x9yE+PuoTSt8KSIrtnNcS61nmwSdz/bASAHYxC+RBpDSAb HoJoErmleWPv64RtJSMPudzOm8UGlhAuibrNfqhle74I34KM4QawyYL4i7Hw3EKpkA6t c9HW6R1iTpu0hTW33LCtZp8mk54uGMTmw0yeRFo2gbS8upbn3+HhDZKEPbZfJY6xOuRF QzVggK19IG7/NtjXkAiguqaptp1VeCTkwQ0cnRgpn11486JREQ8Evz6Ndk5zErokm4gt Si8kCI3ahTjqnEv7CJ67Erh+zuMvEb1wpRY8ljqv4RI2itcW6hM/mO6Ozqb/swQnlKJt StNw== X-Gm-Message-State: AOAM533QPm+dTbXXrgd5aoCdlOI9hlQNSfIAvLVD5jPSFdkBYz8zLde3 zAwmxr+6xe0XZfuLBo1knEJtCcgqhzn58JjOVvk= X-Google-Smtp-Source: ABdhPJxcj7PRkl3JoyIs+xYW3gTrI7UPpzbdEDMrgeZB4ukpZGne7MgK02EzuOLimieqk6uB+EZCe2pTYn5fDzbo/u4= X-Received: by 2002:a4a:dc49:: with SMTP id q9mr14897013oov.85.1607390136755; Mon, 07 Dec 2020 17:15:36 -0800 (PST) MIME-Version: 1.0 References: <20201207051846.CBEEE291CC3F@ary.qy> <7a992502-349c-45a0-ac2a-9ec33aa98035@www.fastmail.com> <347c3c91-476b-a2d1-57c7-a68435fbbf9e@mtcc.com> In-Reply-To: <347c3c91-476b-a2d1-57c7-a68435fbbf9e@mtcc.com> From: Tim Wicinski Date: Mon, 7 Dec 2020 20:15:25 -0500 Message-ID: To: Michael Thomas Cc: IETF DMARC WG Content-Type: multipart/alternative; boundary="0000000000001ded5405b5e9ae1d" Archived-At: Subject: Re: [dmarc-ietf] not ADSP, was is DMARC informational? X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 08 Dec 2020 01:15:39 -0000 --0000000000001ded5405b5e9ae1d Content-Type: text/plain; charset="UTF-8" A good section of our charter is collection Operational experiences. Doing an Operational BCP on DMARC based on data collected is what the WG should do after DMARC-bis. tim On Mon, Dec 7, 2020 at 7:50 PM Michael Thomas wrote: > > On 12/7/20 4:44 PM, Dave Warren wrote: > > On Sun, Dec 6, 2020, at 22:31, Michael Thomas wrote: > >> there are clearly many use cases where that isn't a problem -- like bank > >> transactional mail -- and ADSP was just fine for that. > > There were still surprises to be had here. I still, to this day, find > mail direct from various senders that are wanted by the recipient but that > fails SPF without forwarding (with a -all) or hits a dmarc=reject. I > quarantine such for review and release to users as needed. > > > > Obviously lots is spam, or forwarding that broke SPF or whatever, but > just as often it is a small piece of a big company doing something without > fully understanding how modern email works. Oddly it is often security > sensitive stuff, not crazy long ago it was Facebook password resets, often > it is 2FA codes (which are probably going through a separate channel to get > immediate delivery without risking backlog?), and other reasonably > important things from parts of the company that I would expect to be at > least moderately aware of the email security world. > > > > I agree that ADSP was theoretically fine for this type of use, but in > practice, DMARC's feedback simplifies things a lot when a client complains > their outbound mail isn't making it and we can quickly see what is being > rejected. > > > > it is an imperfect world. > > I fear that DMARC's reporting only confirmed the obvious: this is hard. > It gave numbers to anecdotes. That's really useful, don't get me wrong. > Hopefully it can be used to suss out how to demarcate the long tail of > don't care use cases. > > Mike > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > --0000000000001ded5405b5e9ae1d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

A= good section of our charter is collection Operational experiences. Doing a= n Operational BCP on DMARC based on data collected is what the WG should do= after DMARC-bis.=C2=A0

tim

On Mon, Dec 7, 2020 at 7:50 PM Michael Thomas <mike@mtcc.com> wrote:

On 12/7/20 4:44 PM, Dave Warren wrote:
> On Sun, Dec 6, 2020, at 22:31, Michael Thomas wrote:
>> there are clearly many use cases where that isn't a problem --= like bank
>> transactional mail -- and ADSP was just fine for that.
> There were still surprises to be had here. I still, to this day, find = mail direct from various senders that are wanted by the recipient but that = fails SPF without forwarding (with a -all) or hits a dmarc=3Dreject. I quar= antine such for review and release to users as needed.
>
> Obviously lots is spam, or forwarding that broke SPF or whatever, but = just as often it is a small piece of a big company doing something without = fully understanding how modern email works. Oddly it is often security sens= itive stuff, not crazy long ago it was Facebook password resets, often it i= s 2FA codes (which are probably going through a separate channel to get imm= ediate delivery without risking backlog?), and other reasonably important t= hings from parts of the company that I would expect to be at least moderate= ly aware of the email security world.
>
> I agree that ADSP was theoretically fine for this type of use, but in = practice, DMARC's feedback simplifies things a lot when a client compla= ins their outbound mail isn't making it and we can quickly see what is = being rejected.
>
> it is an imperfect world.

I fear that DMARC's reporting only confirmed the obvious: this is hard.=
It gave numbers to anecdotes. That's really useful, don't get me wr= ong.
Hopefully it can be used to suss out how to demarcate the long tail of
don't care use cases.

Mike

_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
--0000000000001ded5405b5e9ae1d-- From nobody Mon Dec 7 17:20: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 D7A543A0D42 for ; Mon, 7 Dec 2020 17:20:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.651 X-Spam-Level: X-Spam-Status: No, score=-1.651 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mtcc-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W0GqHBuO5i3R for ; Mon, 7 Dec 2020 17:20:38 -0800 (PST) Received: from mail-pf1-x435.google.com (mail-pf1-x435.google.com [IPv6:2607:f8b0:4864:20::435]) (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 A9F133A0D2B for ; Mon, 7 Dec 2020 17:20:38 -0800 (PST) Received: by mail-pf1-x435.google.com with SMTP id w6so12254899pfu.1 for ; Mon, 07 Dec 2020 17:20:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mtcc-com.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=dv4Y+9Gv4R7WoGkP2ElxSri/1PHlABJcwyYpWuqa2bk=; b=W9x9Q3ZggESIVz8xN9oUD4Jz0zVzGONwUaRfq2QzA4VMTChcAihSD+dewLdK6wKqSB xQTDlzr/MtMvmucvxCmNfaK2LR2tDwmP3ViKHlEu1Km6Hv2a5+P9OJIbleBjDvAWxq/X /iNVyATbTnQ9uGJNAt6tFdjMUblNYYDiM74uQdGfxwvuzoaeJArlzZgosX5MvD0d9B8M alqLSpg6ff1bOnnzXOQc3evEFjHwYCoBgLLIME1hnSMGsGL+XQ0fk9DcQ0hINr4IZfGl Gg29Bw0kENMOZAYUlIfRvYhwfW7C2xxh3lReMmKHIrVF9oEzywqBeZjHMad59SeqJyBS rrfg== 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=dv4Y+9Gv4R7WoGkP2ElxSri/1PHlABJcwyYpWuqa2bk=; b=IOxHcwVU9P8uK+uPWoFujGtodOYXbbP61TjHgC22QjWuajYUpV09EsIBctBpFuDYZi CU8c/unEqn2TFsC+oSkT6j84zWiZ21b1/jgwSP1uD/p0ILL1nY79suyE0WX3S1323Uc9 3nwbwmA6Ry5rMrzor7/u+hg0KRBe7SHJ739vezVEp77ZYr1ZzLNP8xeFcLFosmczqz1F fWp/lDvvNvi3+I9k8WqTO+T87pAEfGz74GRBesFghsGQF7LWtk/SPQ8HpKML0gRETsnM vlYLebnHX32ovcJ7j83sI1wlAhnSudCq+1MovmZg5maAOepma8UyrnPrv/Nv9kkqdXq6 Glsw== X-Gm-Message-State: AOAM532BcgPISv560T63SD0c+23hrd/NNTpbSX5R3Gac60QeakqmK5of Nnup3mez925potROrCv9Zm5k0590GPIV+Q== X-Google-Smtp-Source: ABdhPJzpGJCC2QtvBHfIdSNpdZS7BfsOgh6Fea1jM2r7JailuhIGv+CH+lbP2kouncCAVtAx/fKi/Q== X-Received: by 2002:a17:90a:a783:: with SMTP id f3mr1562748pjq.138.1607390437394; Mon, 07 Dec 2020 17:20:37 -0800 (PST) Received: from mike-mac.lan (107-182-41-154.volcanocom.com. [107.182.41.154]) by smtp.gmail.com with ESMTPSA id x6sm12645103pgr.20.2020.12.07.17.20.36 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 07 Dec 2020 17:20:36 -0800 (PST) To: Tim Wicinski Cc: IETF DMARC WG References: <20201207051846.CBEEE291CC3F@ary.qy> <7a992502-349c-45a0-ac2a-9ec33aa98035@www.fastmail.com> <347c3c91-476b-a2d1-57c7-a68435fbbf9e@mtcc.com> From: Michael Thomas Message-ID: <0a562853-dae7-5e7e-f4a8-0c609da9a429@mtcc.com> Date: Mon, 7 Dec 2020 17:20:35 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------658BE1F7854E7589A1220F33" Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] not ADSP, was is DMARC informational? X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 08 Dec 2020 01:20:40 -0000 This is a multi-part message in MIME format. --------------658BE1F7854E7589A1220F33 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 12/7/20 5:15 PM, Tim Wicinski wrote: > > A good section of our charter is collection Operational experiences. > Doing an Operational BCP on DMARC based on data collected is what the > WG should do after DMARC-bis. I guess I don't understand why this should be serialized. When I read over DMARC I completely recognized ADSP/SSP with the addition of SPF policy and reporting. I wouldn't expect a whole lot of changes beyond wordsmithing and some nits around the edges. If this is really because large mail providers have started using p=reject, that seems to be pushing off the actual payload way down the line. Standards track is not going to change this much, IMO. Mike --------------658BE1F7854E7589A1220F33 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit


On 12/7/20 5:15 PM, Tim Wicinski wrote:

A good section of our charter is collection Operational experiences. Doing an Operational BCP on DMARC based on data collected is what the WG should do after DMARC-bis. 

I guess I don't understand why this should be serialized. When I read over DMARC I completely recognized ADSP/SSP with the addition of SPF policy and reporting. I wouldn't expect a whole lot of changes beyond wordsmithing and some nits around the edges. If this is really because large mail providers have started using p=reject, that seems to be pushing off the actual payload way down the line. Standards track is not going to change this much, IMO.

Mike


--------------658BE1F7854E7589A1220F33-- From nobody Mon Dec 7 17:28: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 E51863A0D7B for ; Mon, 7 Dec 2020 17:27:59 -0800 (PST) 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 hkoeupJWtoNm for ; Mon, 7 Dec 2020 17:27:58 -0800 (PST) Received: from mail-oi1-x230.google.com (mail-oi1-x230.google.com [IPv6:2607:f8b0:4864:20::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91A883A0D43 for ; Mon, 7 Dec 2020 17:27:55 -0800 (PST) Received: by mail-oi1-x230.google.com with SMTP id s2so8270442oij.2 for ; Mon, 07 Dec 2020 17:27:55 -0800 (PST) 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=SKFn3lV8+AP1Gf5z0v/D0Zg7X5Vp/D+c2ducSNfkAEY=; b=TCNl0sKhDyUOgq0JlVoCDmOdGU/GoupU6UMBVnEK3kOAiInrtmncigGGEb9jF6h+0x 2bynsC7AulrH9w5oqRiSL9pWPqnsYntlut23+RrEYmBIwVfM4TFuQj0yWcuoyL6WwPMP Hdz7x52a8iV5gVUdJ+fe7ZEEzZqstfe+cuDEF80sVRgVsV6YlxZpmj/sr9LUEXEy0Lfu 1O/+P33UaiUQ+7/vbHzHb9Ja+YLRycaxg9l8xIrRP01+kCQPorrhFCxut85zoFvpVKz8 0ZhSON7q2RKzXCRAcQj6P1IvAsjTs52Cc28fNtL/2OTk4YK9+i+SxS4aIzaOFXfa88Uc c00w== 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=SKFn3lV8+AP1Gf5z0v/D0Zg7X5Vp/D+c2ducSNfkAEY=; b=BdHaA82aLduKk6kFQ1XeH3ch9O8DjqX0WvxAP/OXpHBtsqwm5/2PKzQ38bcb5RiZ2g BomdlP+PpddWA6iAA8zuiZbtHovhDZTGhkPEALreCBozDlRGL0kjFz+rglAJkrUuNlfA L5hiQPJll6RSougJ92AWPNiUBNToKZf2tvHKKnOoaf/ObTObNKftQMjFT+K1zcmNbO9/ SGzMo9onehCRhM1Gc77kIWt+4mb5BHXWy/ZnbRifLVDw8W/xaa/o0aw4TmLbjfqVIM4j 1px078K0yh2pgDFckxuRUL1ZxhieDrCKW/7GcSFIZGgeavtrMCvfbfHg8QITmhSRy5OI iB6w== X-Gm-Message-State: AOAM530hhEWpmK6AAdQiQkreSFLJa+3VAKt/Q2f8GzT6IMO9IByhiUTr S88aKZySWOvZSV/va/Yc4fahnR8mdUA4YlMpspo= X-Google-Smtp-Source: ABdhPJwqiTUqI+KBNkcTs0zDX7wGk22SRFMRnX9a5Gc8++fz4QAhBdDqMH8N4F4MIoQwUoyTAtmEQrlN1rqiII/dAf8= X-Received: by 2002:aca:c3c6:: with SMTP id t189mr1132180oif.21.1607390874975; Mon, 07 Dec 2020 17:27:54 -0800 (PST) MIME-Version: 1.0 References: <20201207051846.CBEEE291CC3F@ary.qy> <7a992502-349c-45a0-ac2a-9ec33aa98035@www.fastmail.com> <347c3c91-476b-a2d1-57c7-a68435fbbf9e@mtcc.com> <0a562853-dae7-5e7e-f4a8-0c609da9a429@mtcc.com> In-Reply-To: <0a562853-dae7-5e7e-f4a8-0c609da9a429@mtcc.com> From: Tim Wicinski Date: Mon, 7 Dec 2020 20:27:44 -0500 Message-ID: To: Michael Thomas Cc: IETF DMARC WG Content-Type: multipart/alternative; boundary="0000000000001e405d05b5e9daee" Archived-At: Subject: Re: [dmarc-ietf] not ADSP, was is DMARC informational? X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 08 Dec 2020 01:28:04 -0000 --0000000000001e405d05b5e9daee Content-Type: text/plain; charset="UTF-8" There are a number of open issues and you open more. https://trac.ietf.org/trac/dmarc/report/1 I think it is being serialized for lack of people and also WG energy. tim On Mon, Dec 7, 2020 at 8:20 PM Michael Thomas wrote: > > On 12/7/20 5:15 PM, Tim Wicinski wrote: > > > A good section of our charter is collection Operational experiences. Doing > an Operational BCP on DMARC based on data collected is what the WG should > do after DMARC-bis. > > I guess I don't understand why this should be serialized. When I read over > DMARC I completely recognized ADSP/SSP with the addition of SPF policy and > reporting. I wouldn't expect a whole lot of changes beyond wordsmithing and > some nits around the edges. If this is really because large mail providers > have started using p=reject, that seems to be pushing off the actual > payload way down the line. Standards track is not going to change this > much, IMO. > > Mike > > --0000000000001e405d05b5e9daee Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
There are a number of open issues and you open more.=C2=A0https://trac.ietf.org/trac/dmarc/re= port/1

I = think it is being serialized for lack of people and also WG energy.=C2=A0

=
tim

On Mo= n, Dec 7, 2020 at 8:20 PM Michael Thomas <mike@mtcc.com> wrote:
=20 =20 =20


On 12/7/20 5:15 PM, Tim Wicinski wrote:
=20

A good section of our charter is collection Operational experiences. Doing an Operational BCP on DMARC based on data collected is what the WG should do after DMARC-bis.=C2=A0

I guess I don't understand why this should be serialized. When I read over DMARC I completely recognized ADSP/SSP with the addition of SPF policy and reporting. I wouldn't expect a whole lot of changes beyond wordsmithing and some nits around the edges. If this is really because large mail providers have started using p=3Dreject, that seems to be pushing off the actual payload way down the line. Standards track is not going to change this much, IMO.

Mike


--0000000000001e405d05b5e9daee-- From nobody Mon Dec 7 17:36: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 B937A3A0BF3 for ; Mon, 7 Dec 2020 17:36:57 -0800 (PST) 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 95XrrVRqAar2 for ; Mon, 7 Dec 2020 17:36:55 -0800 (PST) Received: from mail-ua1-x935.google.com (mail-ua1-x935.google.com [IPv6:2607:f8b0:4864:20::935]) (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 497793A0B17 for ; Mon, 7 Dec 2020 17:36:55 -0800 (PST) Received: by mail-ua1-x935.google.com with SMTP id y26so5155442uan.5 for ; Mon, 07 Dec 2020 17:36:55 -0800 (PST) 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=2OeVn86l6Dbnky0RlhLQVsYMRzVWFmnfs9bqmyRxLF0=; b=r/lataonwFaqbpkJ3RQwHKAdCWvRnKeMrS//uSH9dc9wNyLQuWP/cY3Qt7UwgLV8wS YZvu9Gz8n92d81pySmecgyv+b4SEg1HfLWqkgC7CqXKHT5i30Qt+eCO7jClVCitO9oW6 VWlwJhe8Ns8xSa1XOgw0FVx0FGr+vOCNti3yd2qODAnMl/b9FzJx45f6fnQiHm+L1utC OLV/+EHu8e2uEgqPf8GbgMloab1tYRGAd7vH75A+9pDsTH9LiEWrYDqj45U7Gnn9f2li QTNcSgKUWIw+oDPlShvc/YFTdmGXRjuVrM+KLWG5VuzSAUmtRHbp2HFmUo1kMDczpt9k xrLQ== 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=2OeVn86l6Dbnky0RlhLQVsYMRzVWFmnfs9bqmyRxLF0=; b=nYdeoaqrHpSkj7wlC+Lsn20UD5oNGglO+WrugraWWMepkah7HJ5VsJS8J8HBUK+q1o frzvpmlZytpHK8NGIahc39TFJ/wDhTC9rT6CclA0qHdoZ85LTV9yLJih+KTpnwFsvHp7 aRCZxMN/9YqzvH9dBV6ML28CkBLYvhT938TX3roBrjiDF8uDMoekAR4PPNCc6P7flBus 51O56UfbyIBMAXvp+BTU4LZtz7FS0xazYXgaz3FsquPv0/HL4AXCCiVtVyQeRM+1unLA O16DtUNXMY6Rt0gqx7CWIweqff9/IdQyrqoNQZJxXZcoaZHFMclZwOIv4emFic7cbI5i l/4A== X-Gm-Message-State: AOAM532vzAdgaB+yqpCMuTKIAB26zqW/HFEpJIfRBkminqetjl5hyU5j +HDleoTdGYutoX7AmEvYAE1OyBnBoLEK7yIAgi3ICLPfx06v X-Google-Smtp-Source: ABdhPJzWKE1frCDahmZpi+hctN9b7czPawkS0CSm9sAshj2qggVkBVQjnCyIa8DHvVkHl6lZmlNyYzChNvOQiJdR+4I= X-Received: by 2002:ab0:55da:: with SMTP id w26mr12065099uaa.31.1607391414093; Mon, 07 Dec 2020 17:36:54 -0800 (PST) MIME-Version: 1.0 References: <8c83fffc-077d-9ddb-db2f-b9763361c60f@tana.it> <39eafc5e-3d9c-0bea-1173-7277070195ea@wisc.edu> <081c42a3-492b-89b7-ad76-ccec48dea091@tana.it> <2d1dca4f-e46a-646c-9fa3-d9ca56c72196@tana.it> <01d1849f-6a0a-5307-db54-7587e33fc018@tana.it> In-Reply-To: From: Brandon Long Date: Mon, 7 Dec 2020 17:36:41 -0800 Message-ID: To: Alessandro Vesely Cc: IETF DMARC WG Content-Type: multipart/alternative; boundary="00000000000041271105b5e9fa7f" Archived-At: Subject: Re: [dmarc-ietf] A policy for direct mail flows only, was ARC questions X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 08 Dec 2020 01:36:58 -0000 --00000000000041271105b5e9fa7f Content-Type: text/plain; charset="UTF-8" On Sat, Dec 5, 2020 at 5:20 AM Alessandro Vesely wrote: > On Fri 04/Dec/2020 23:45:47 +0100 Brandon Long wrote: > > On Wed, Dec 2, 2020 at 3:11 AM Alessandro Vesely wrote: > >> On Wed 02/Dec/2020 03:14:46 +0100 Brandon Long wrote: > >>> On Tue, Dec 1, 2020 at 2:37 AM Alessandro Vesely > wrote: > >>>> On Tue 01/Dec/2020 05:56:46 +0100 Brandon Long wrote: > >>>>> On Thu, Nov 26, 2020 at 12:59 AM Alessandro Vesely > wrote: > >>>>>> On 25/11/2020 20:16, Michael Thomas wrote: > >>>>>>> On 11/25/20 11:11 AM, Alessandro Vesely wrote: > >>>>>>>> On 25/11/2020 19:24, Jesse Thompson wrote: > >>>>>>>>> On 11/25/20 11:30 AM, Alessandro Vesely wrote: > >>>>>>>>>> Without resorting to ARC, it is still possible to validate > >>>>>>>>>> author domain's signatures directly if the MLM just adds a > >>>>>>>>>> subject tag and a footer >>>>>>>>> > >>>>>>>>> I agree that ARC isn't really needed to do this (trust the > >>>>>>>>> last hop from the MLM and determine the original > >>>>>>>>> authenticity from the MLM's perspective) >>>>>>>> > >>>>>>>> I didn't mean to trust the MLM. I meant remove the subject > >>>>>>>> tag and the footer, then the original DKIM signature verifies. > >>>>>>>> See: > >>>>>>>> > https://datatracker.ietf.org/doc/draft-vesely-dmarc-mlm-transform/ >>>>>>> > >>>>>>> When I was at Cisco, with l= and some subject line heuristics I > >>>>>>> could get probably like 90+% verification rate across the entire > >>>>>>> company, a company that uses external mailing lists a lot. > >>>>>>> Definitely not 100% though. >>>>>> > >>>>>> DKIM itself is not 100%. You always have lines beginning with > >>>>>> "From " or occasional autoconversions. >>>>>> > >>>>>> l= doesn't cover multipart/alternative nor > >>>>>> Content-Transfer-Encoding: base64. In addition, the DKIM spec > >>>>>> discourages its usage and suggests that "Assessors might wish to > >>>>>> ignore signatures that use the tag." >>>>> > >>>>> Right, some of the other dkim-light or diff concepts we discussed > >>>>> would be better than using l= >>>>> > >>>>> We again got hung up on the 100% solution, though... something that > >>>>> handled subject-prefix and footer in a transport agnostic way might > >>>>> have worked. >>>> > >>>> I'm not clear about the meaning of "100%". If an author domain puts > >>>> no DKIM signatures, there is no way to verify them. Hence, some > >>>> compliance of the author domain has to be required. >>>> > >>>> The same holds for conditional signatures. > >>>> > >>>> The same holds for MLM transformations. > >>> > >>> Yes, by 100% I meant of messages that were already authenticated and > >>> therefore should continue to be authenticated through the relay. >> > >> That's ARC. If a message lacks DKIM and was SPF-authenticated, there's > >> no way it can continue to be authenticated through a relay. >> > >> OTOH, mailing lists and relays are two different beasts. For one thing, > >> it is very unusual for a mailing list to send to another mailing list. > >> Thus, we can safely specify a non-stackable authentication method. > > > mailing list to mailing list mail is very common in GSuite, but maybe > we're > > a special case. Part of that was that aliases were moved to the mailing > > list infra (which is definitely more of an "our problem" than everyone), > but > > we also see common usage where companies make groups matching their > > hierarchy (the all company group goes to all department groups which go > to > > all local groups etc). We also see some where announce groups mix > contrib > > groups, etc. Especially since we also use the same groups as ACL groups > for > > GSuite and Google Cloud, so hierarchical groups are very common. > > I'm not familiar with that feature. How does a list get subscribed to > another > list? > Either by direct add via the groups interface, via carefully crafted +subscribe emails, or via our directory API: https://developers.google.com/admin-sdk/directory/v1/guides/manage-group-members The consumer version of groups tries to not let other groups subscribe by looking at the subscribing domain, but the workspace version doesn't care. > In general, a list accepts messages from subscribed users, so if > dmarc-ietf > distributed this message to another list which I'm not a subscriber of, it > would not pass. (From: rewriting changes that behavior. For example, one > could subscribe to a list which routinely rewrites From: on behalf of this > list, dmarc-ietf. If the former list traffic is very high, that > subscribing > could be a sort of DoS attack to us.) > Yes, having lists subscribed to lists creates all sorts of complications. > > (there was a recent common where someone said who needs an org chart > when > > we have email, showing the list of footers for all of the org level > mailing > > lists the message went to to get to them) > > The mlm-transform draft (referenced above) limits footers to 10 lines of > text, > each shorter than 80 characters. If the hierarchy is not deeper than 10, > the > chart can fit within a single footer. Note that every added line breaks > all > previous signatures. However, only the author domain's signature is worth > being recovered, as far as MLM transformations are concerned. ARC can > still > certify the whole chain. > > The 10 lines limit is arbitrary. It is meant to avoid that recipients > mistake > the footer for the main part of the message. > > > > (one construction of hierarchical announce lists that was not well > > considered did result in every person on the combined list getting 9000 > > copies of messages to the list, so flattening lists is sometimes much > > preferred) > > > Which isn't to say we couldn't work around it or do the work to flatten > the > > lists, though it increases the complexity of the product (can you > > unsubscribe from the top level list but not a sub list?) > > I guess some coordination among sublists is required anyway. > Note that sub-lists may not be from the same list manager, ie one could subscribe alias type lists to lists at other domains. > To recognize that a message arrives from a sublist, and hence mangle the > existing footer instead of adding a new one, is certainly an added > complexity. > Maybe, the number of lists in such condition is low enough to let MLM > transformation reversion still worth being deployed? I think something like mlm-transform is not a 100% solution, though how useful would depend on whether it's a 50% or 99% solution. Frankly, I think some of the other restrictions might eliminate more email, but we'd have to look at the numbers. Brandon --00000000000041271105b5e9fa7f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Sat, Dec 5, 2020 at 5:20 AM Alessa= ndro Vesely <vesely@tana.it> wr= ote:
On Fri 04/D= ec/2020 23:45:47 +0100 Brandon Long wrote:
> On Wed, Dec 2, 2020 at 3:11 AM Alessandro Vesely <vesely@tana.it> wrote:
>> On Wed 02/Dec/2020 03:14:46 +0100 Brandon Long wrote:
>>> On Tue, Dec 1, 2020 at 2:37 AM Alessandro Vesely <vesely@tana.it> wrote:<= br> >>>> On Tue 01/Dec/2020 05:56:46 +0100 Brandon Long wrote:
>>>>> On Thu, Nov 26, 2020 at 12:59 AM Alessandro Vesely <= ;vesely@tana.it>= wrote:
>>>>>> On 25/11/2020 20:16, Michael Thomas wrote:
>>>>>>> On 11/25/20 11:11 AM, Alessandro Vesely wrote:=
>>>>>>>> On 25/11/2020 19:24, Jesse Thompson wrote:=
>>>>>>>>> On 11/25/20 11:30 AM, Alessandro Vesel= y wrote:
>>>>>>>>>> Without resorting to ARC, it is st= ill possible to validate
>>>>>>>>>> author domain's signatures dir= ectly if the MLM just adds a
>>>>>>>>>> subject tag and a footer >>&= gt;>>>>>>
>>>>>>>>> I agree that ARC isn't really need= ed to do this (trust the
>>>>>>>>> last hop from the MLM and determine th= e original
>>>>>>>>> authenticity from the MLM's perspe= ctive) >>>>>>>>
>>>>>>>> I didn't mean to trust the MLM.=C2=A0 = I meant remove the subject
>>>>>>>> tag and the footer, then the original DKIM= signature verifies.
>>>>>>>> See:
>>>>>>>> h= ttps://datatracker.ietf.org/doc/draft-vesely-dmarc-mlm-transform/ >&= gt;>>>>>
>>>>>>> When I was at Cisco, with l=3D and some subjec= t line heuristics I
>>>>>>> could get probably like 90+% verification rate= across the entire
>>>>>>> company, a company that uses external mailing = lists a lot.
>>>>>>> Definitely not 100% though. >>>>&g= t;>
>>>>>> DKIM itself is not 100%.=C2=A0 You always have lin= es beginning with
>>>>>> "From " or occasional autoconversions. &= gt;>>>>>
>>>>>> l=3D doesn't cover multipart/alternative nor >>>>>> Content-Transfer-Encoding: base64. In addition, th= e DKIM spec
>>>>>> discourages its usage and suggests that "Asse= ssors might wish to
>>>>>> ignore signatures that use the tag." >>= >>>
>>>>> Right, some of the other dkim-light or diff concepts w= e discussed
>>>>> would be better than using l=3D >>>>> >>>>> We again got hung up on the 100% solution, though... s= omething that
>>>>> handled subject-prefix and footer in a transport agnos= tic way might
>>>>> have worked. >>>>
>>>> I'm not clear about the meaning of "100%".= =C2=A0 If an author domain puts
>>>> no DKIM signatures, there is no way to verify them.=C2=A0 = Hence, some
>>>> compliance of the author domain has to be required. >&g= t;>>
>>>> The same holds for conditional signatures.
>>>>
>>>> The same holds for MLM transformations.
>>>
>>> Yes, by 100% I meant of messages that were already authenticat= ed and
>>> therefore should continue to be authenticated through the rela= y. >>
>> That's ARC.=C2=A0 If a message lacks DKIM and was SPF-authenti= cated, there's
>> no way it can continue to be authenticated through a relay. >&g= t;
>> OTOH, mailing lists and relays are two different beasts.=C2=A0 For= one thing,
>> it is very unusual for a mailing list to send to another mailing l= ist.
>> Thus, we can safely specify a non-stackable authentication method.= >
> mailing list to mailing list mail is very common in GSuite, but maybe = we're
> a special case.=C2=A0 Part of that was that aliases were moved to the = mailing
> list infra (which is definitely more of an "our problem" tha= n everyone), but
> we also see common usage where companies make groups matching their > hierarchy (the all company group goes to all department groups which g= o to
> all local groups etc).=C2=A0 We also see some where announce groups mi= x contrib
> groups, etc.=C2=A0 Especially since we also use the same groups as ACL= groups for
> GSuite and Google Cloud, so hierarchical groups are very common.

I'm not familiar with that feature.=C2=A0 How does a list get subscribe= d to another
list?

Either by direct add via the grou= ps interface, via carefully crafted=C2=A0+subscribe emails,=C2=A0
or via our directory API:
<= div>
The consumer version of groups tries to not let other gr= oups subscribe by looking at the
subscribing domain, but the work= space version doesn't care.
=C2=A0
In general, a list accepts messages from subscribed users, so if dmarc-ietf=
distributed this message to another list which I'm not a subscriber of,= it
would not pass.=C2=A0 (From: rewriting changes that behavior.=C2=A0 For exa= mple, one
could subscribe to a list which routinely rewrites From: on behalf of this =
list, dmarc-ietf.=C2=A0 If the former list traffic is very high, that subsc= ribing
could be a sort of DoS attack to us.)

Y= es, having lists subscribed to lists creates all sorts of complications.
=C2=A0
> (there was a recent common where someone said who needs an org chart w= hen
> we have email, showing the list of footers for all of the org level ma= iling
> lists the message went to to get to them)

The mlm-transform draft (referenced above) limits footers to 10 lines of te= xt,
each shorter than 80 characters.=C2=A0 If the hierarchy is not deeper than = 10,=C2=A0 the
chart can fit within a single footer.=C2=A0 Note that every added line brea= ks all
previous signatures.=C2=A0 However, only the author domain's signature = is worth
being recovered, as far as MLM transformations are concerned.=C2=A0 ARC can= still
certify the whole chain.

The 10 lines limit is arbitrary.=C2=A0 It is meant to avoid that recipients= mistake
the footer for the main part of the message.


> (one construction of hierarchical announce lists that was not well > considered did result in every person on the combined list getting 900= 0
> copies of messages to the list, so flattening lists is sometimes much =
> preferred) >
> Which isn't to say we couldn't work around it or do the work t= o flatten the
> lists, though it increases the complexity of the product (can you
> unsubscribe from the top level list but not a sub list?)

I guess some coordination among sublists is required anyway.

Note that sub-lists may not be from the same list man= ager, ie one could
subscribe alias type lists to lists at other d= omains.
=C2=A0
To recognize that a message arrives from a sublist, and hence mangle the existing footer instead of adding a new one, is certainly an added complexi= ty.
=C2=A0 Maybe, the number of lists in such condition is low enough to let ML= M
transformation reversion still worth being deployed?

<= /div>
I think something like mlm-transform is not a 100% solution, thou= gh how useful would
depend on whether it's a 50% or 99% solut= ion.=C2=A0 Frankly, I think some of the other restrictions
might = eliminate=C2=A0more=C2=A0email, but we'd have to look at the numbers.

Brandon
--00000000000041271105b5e9fa7f-- From nobody Mon Dec 7 17:55: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 8EC3E3A0C62 for ; Mon, 7 Dec 2020 17:55:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.6 X-Spam-Level: X-Spam-Status: No, score=-17.6 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, 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 C9suORxCnZ22 for ; Mon, 7 Dec 2020 17:55:29 -0800 (PST) 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 D796A3A0C11 for ; Mon, 7 Dec 2020 17:55:28 -0800 (PST) Received: by mail-vs1-xe33.google.com with SMTP id h6so8725216vsr.6 for ; Mon, 07 Dec 2020 17:55:28 -0800 (PST) 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=OXIxc1d0NSbhipS5vyd5xOYDfoYWwn+5pnUvsvBRKmo=; b=X3qNxHlB2O/OCEeFpNXQIx/I2uFSjOJ51IixfddcF8IwOhrTRO/AWfMLcXojUrJvpu 3tkEkMvMUKW2Rm/eVt5uWLjyZlg3ijniPm/hGvLFdYHxArpDvyp0iEdXKCq5mCw4hdUg wm/Gaz0gtIe4bOuoB7xoYIAiREdNWjuk+FMRZ6fbGADEKwJKXKwP9SJiwlptiRMQdVc2 n7hNtIfyElVpnR2nzEWCtfQ8pUmnfosBTDCxdyR4SO6QDnJSHncWcNvGMc2Dcr7kZDWM g1jdIhfsqr82glWxw3AAUWtAzl5KtTRTeHJyRklgAGeSpUv8TC3PGOOAOU7K6Abn2vwZ ftBQ== 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=OXIxc1d0NSbhipS5vyd5xOYDfoYWwn+5pnUvsvBRKmo=; b=gIFIcUbS2adEVOe2lrwe5Ow9gKBNSbUAF2EguO4e8xd5BOf29WyRFnxvBP0TdMMX5I ZR72FN5dsWC5kANAIb6yB22Oen08OshcD0jUmwbziOYuRJIu2az76jMO/5dWlf557+1K ygJKT0hRPPaj6AFv9JLEUjIZlue228hpGG7YGL0yplEVvvMX3fHBx4dFZCYe1Y/f8Lpu +RmwQcfkO3WxiKAt//oXGUSDlBZ3Qwb00B+xGtwCz80pSgCOwDghKJJSs53OIcCb/VSy nfySBawwdADe+PL2kBUMz2Rjp9lc0+W8YRkUjiGC9odtdhZO4PsYGH/2Q/G1hCNRz3vs qM3g== X-Gm-Message-State: AOAM533C6rGCmv4JXzYSukwWPOGdr8LgKeEfCh25f/VQsm5eqH1Ht9Zp 1iqESoawZDGcDm0uWcNxAkNR1KmDsNrKpaaOIAEb X-Google-Smtp-Source: ABdhPJwxbxOrg49fgJDfLAbAqZoSiSPQSXu1y7+V1UKoIlnRoThZHue4CqEFat5gxjO+zF2zQCm38O64MslHHA0wyHA= X-Received: by 2002:a67:e90d:: with SMTP id c13mr14685847vso.0.1607392527593; Mon, 07 Dec 2020 17:55:27 -0800 (PST) MIME-Version: 1.0 References: <20201202021651.E8EE128C576A@ary.qy> <327860af-2fa7-63ee-4b89-6e7e383f3d53@crash.com> <2804da89-84d1-f601-9425-0b0d9baf6ae1@gmail.com> <1f6cae74-4eed-47f5-7249-e526bf1f5845@crash.com> <87y2ig9t9i.fsf@orion.amorsen.dk> In-Reply-To: From: Brandon Long Date: Mon, 7 Dec 2020 17:55:15 -0800 Message-ID: To: "Murray S. Kucherawy" Cc: Dotzero , IETF DMARC WG , Benny Lyne Amorsen Content-Type: multipart/alternative; boundary="0000000000009f933905b5ea3cc7" Archived-At: Subject: Re: [dmarc-ietf] Ticket #39 - remove p=quarantine X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 08 Dec 2020 01:55:30 -0000 --0000000000009f933905b5ea3cc7 Content-Type: text/plain; charset="UTF-8" On Wed, Dec 2, 2020 at 11:09 AM Murray S. Kucherawy wrote: > On Wed, Dec 2, 2020 at 6:47 AM Dotzero wrote: > >> p= DID NOT mistakenly choose to use the language of receiver actions. p= >> represents the domain-owner request to the receiver as to the disposition >> of messages which fail to validate. Any reading of "concern" is supposition >> on the part of yourself or other self appointed interpreters of the mind of >> the domain-owner or administrator. The vocabulary is perfectly fine as it >> accurately describes the request being made. It makes no attempt to read >> the underlying reasoning behind the request because, surprisingly, there is >> likely to be a wide range of underlying reasoning behind why various >> domains publish the policies they publish. This is an interoperability >> standard, not a seance. >> > > Not sure I agree. > > I have long held a quiet dislike for "quarantine" because that has a > particular meaning to milter implementations. Specifically, milter can > render one of several final results about a message, one of which is > actually called "quarantine". It means "park this in the queue > indefinitely until a human decides what to do with it." There's no > indication to the operator that such a job is waiting for review unless one > goes and looks for such things. The upshot of this is that quarantining in > that environment can become a denial of service attack if I send you enough > messages that end up getting handled that way and your queue disk fills, or > the queue takes an inordinately long time to process because these have > piled up and need to be inspected. > > Certainly not all implementers will trip on this (maybe none will) but > it's an argument to me in favor of picking a word or set of words that > describe what the domain owner thinks of the message, rather than what the > domain owner thinks you should do with it. > Hmm, reading this thread, I think one missing feature in the dmarc spec is passing the expected disposition in the authres header, since presumably the evaluation is at smtp time, but the mailbox delivery itself would need to know it. One could use the dmarc= names and look up the dmarc policy itself to also figure that out with some amount of work. I know that Gmail and others put that information in the comments, but that probably shouldn't be for something explicitly part of the spec like this. Anyways, +1 to keeping p=quarantine as a concept, but willing to go along with the consensus on naming. Brandon --0000000000009f933905b5ea3cc7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Dec 2, 2020 at 11:09 AM Murra= y S. Kucherawy <superuser@gmail.com> wrote:
On Wed, Dec 2, 2020 a= t 6:47 AM Dotzero <dotzero@gmail.com> wrote:
p=3D DID NOT= mistakenly choose to use the language of receiver actions. p=3D represents= the domain-owner request to the receiver as to the disposition of messages= which fail to validate. Any reading of "concern" is supposition = on the part of yourself or other self appointed interpreters of the mind of= the domain-owner or administrator. The vocabulary is perfectly fine as it = accurately describes the request being made. It makes no attempt to read th= e underlying reasoning behind the request because, surprisingly, there is l= ikely to be a wide range of underlying reasoning behind why various domains= publish the policies they publish. This is an interoperability standard, n= ot a seance.

Not sure I agree.

I have long held a quiet dislike for "quarantin= e" because that has a particular meaning to milter implementations.=C2= =A0 Specifically, milter can render one of several final results about a me= ssage, one of which is actually called "quarantine".=C2=A0 It mea= ns "park this in the queue indefinitely until a human decides what to = do with it."=C2=A0 There's no indication to the operator that such= a job is waiting for review unless one goes and looks for such things.=C2= =A0 The upshot of this is that quarantining in that environment can become = a denial of service attack if I send you enough messages that end up gettin= g handled that way and your queue disk fills, or the queue takes an inordin= ately long time to process because these have piled up and need to be inspe= cted.

Certainly not all implementers will trip on = this (maybe none will) but it's an argument to me in favor of picking a= word or set of words that describe what the domain owner thinks of the mes= sage, rather than what the domain owner thinks you should do with it.
=

Hmm, reading this thread, I th= ink one missing feature in the dmarc spec is passing the expected dispositi= on in the authres header, since presumably the evaluation is at smtp time, = but the mailbox
delivery itself would need to know it.=C2=A0 One = could use the dmarc=3D names and look up the dmarc policy itself to also fi= gure that out with some amount of work.

I know tha= t Gmail and others put that information in the comments, but that probably = shouldn't be for something explicitly part of the spec like this.
=

Anyways,=C2=A0+1 to keeping p=3Dquarantine as a concept= , but willing to go along with the consensus on naming.

Brandon=C2=A0
--0000000000009f933905b5ea3cc7-- From nobody Mon Dec 7 18:25: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 99E873A0D89 for ; Mon, 7 Dec 2020 18:25:55 -0800 (PST) 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 (2048-bit key) header.d=iecc.com header.b=pbGwji1T; dkim=pass (2048-bit key) header.d=taugh.com header.b=AzXVub39 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9bZEv_FQYWbH for ; Mon, 7 Dec 2020 18:25:54 -0800 (PST) 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 AF9C63A0D76 for ; Mon, 7 Dec 2020 18:25:53 -0800 (PST) Received: (qmail 77108 invoked from network); 8 Dec 2020 02:25: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=12d32.5fcee42c.k2012; i=johnl-iecc.com@submit.iecc.com; bh=0DBc4w+Oy/sGLXWD8oVKSdELiIZHfrfqqa5zQN6MvqE=; b=pbGwji1T3JVG1MTNKKaFLemTEtvdfaqlLedCwREs3NWXF+A99+XuusGzMOS4uSR6jFydMri7OtUBgujlvb/fc+aRB7w8WP9Vsq+30OaEeJV01x+16sHCWjIWUvjGvTin50LC0qXVtRcxz4F4B+xsuqAnzRcJV8/wGEHxo9M5rLQ44Ecbed4/unImaYLFltTYNikci5vSRrcmCZQaTa4KuIrH+0nwhParUeqjvoCc1WOvCs0uHQvueVL4kPQTPFQkJ7X0q7RWUBnFyPJCBABIa04vZG7bs2ThmLJdvC9hvX9FBOf8Q9kdAqEYljhZFkG44UN9K0KKCEJIdOaKpJYlIg== 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=12d32.5fcee42c.k2012; olt=johnl-iecc.com@submit.iecc.com; bh=0DBc4w+Oy/sGLXWD8oVKSdELiIZHfrfqqa5zQN6MvqE=; b=AzXVub39z/yJGoZ1TwwqTBbygpSjU2Q5EKd51eh72co2zfLEf3CPK6jJYMc4Z5yJKLqmN/e/Bfo/F/XfEJe907WuHUuy1JSEQVr3X/I0u8hzKbgsYN4FY2za73QKHqLpKO/29YsgH+I8D4ybgu4yWcziM+yuxMcPU9Q170aIgfTyOhLC4dGKtiA179fP34vTY0BOVijV5XBkaTvAODTGbjGy4Xr/p18J1wEbU2ugwkYUNWFyN+w32TYlGJxrL7ozwEp8A1jcNHeRtnDC9+8RiUlSUARSPNcs6fmp3C/efvGce8ogusp2Z5VEciYYyJzFqF5ZDh+hBWTcjfzhIL2K/A== 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; 08 Dec 2020 02:25:48 -0000 Date: 7 Dec 2020 21:25:47 -0500 Message-ID: <90597428-e6d-9f3e-2ae3-99a16e13487@taugh.com> From: "John R Levine" To: "Jim Fenton" Cc: dmarc@ietf.org In-Reply-To: <5EFCDAFF-26EF-4FC1-B7E2-E44CA66872BB@bluepopcorn.net> References: <20201207051846.CBEEE291CC3F@ary.qy> <5EFCDAFF-26EF-4FC1-B7E2-E44CA66872BB@bluepopcorn.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="0-319825755-1607394348=:68481" Archived-At: Subject: Re: [dmarc-ietf] not ADSP, was is DMARC informational? X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 08 Dec 2020 02:25:56 -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-319825755-1607394348=:68481 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT On Mon, 7 Dec 2020, Jim Fenton wrote: > Agree, the reporting is great. But so much of the marketing/mandates I see > around DMARC doesn’t tell domain owners to turn on reporting first to see > what’s broken, it tells them to publish a DMARC p=reject policy because they > have a security vulnerability if they don’t. If the guidance around DMARC was > to publish a p=reject policy only “if it’s safe to do so” (meaning mostly for > transactional domains), I’d be a lot happier with it. Yes indeed. It's pretty much the same issue as people who have DMARC on a checklist so they publish an SPF record and p=reject, check the item, and I'm stuck with mail that disappears when I forward it to its intended recipient. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly --0-319825755-1607394348=:68481-- From nobody Mon Dec 7 18: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 9D8633A0B5D for ; Mon, 7 Dec 2020 18:37:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.851 X-Spam-Level: X-Spam-Status: No, score=-1.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iecc.com header.b=feU0ABBi; dkim=pass (2048-bit key) header.d=taugh.com header.b=k4ruulhp Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pi92_8P4_2b9 for ; Mon, 7 Dec 2020 18:37:47 -0800 (PST) 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 DDB3D3A0639 for ; Mon, 7 Dec 2020 18:37:46 -0800 (PST) Received: (qmail 79828 invoked from network); 8 Dec 2020 02:37: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:cleverness; s=137ce.5fcee6f9.k2012; bh=sN+8kCXoZQQ7ipzqqWW/uHG9pMSgbSv17ji3iwSmWRU=; b=feU0ABBiajgNSvZcxYPJaTf88q9PZAQtv6hJZcVL5cb/uL1/OUcIW0qgwgcZ1exDp9M/qFI+zD/5msh6z85gmWEGAGCJI0IZVbOS/PsDcNKWrorm9fFZoF+OEmXV2QRdFfZXP5Us7TOXWSIAd2rniAqDnB2IcdIpyHfsCYDzWPOVfeAwt8Ldmrb6MMQojme9+VlLrHW7nGrZ3r3KaW1H+KK+dg7vc1phmHt7eOSWUTV8qqOYkzrUGVKbjf1NWaIjEF0owu+8Qm7GOFlawsIcr6B6g8teJZicoePkS6Nv6xeD6wAuaroAFU21MlbvKgzfHRHo0Hvl3HO4tsR+p27x0w== DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=137ce.5fcee6f9.k2012; bh=sN+8kCXoZQQ7ipzqqWW/uHG9pMSgbSv17ji3iwSmWRU=; b=k4ruulhphwFE+N98JOTaQcbRGOk2hKTcQv2fetXLsMGKb+UDfPdlQ3UwRNjeUSB3LI2l++84za8msJ4mw/6OhyN9XG8lF0dxuWGAZOlhbtwx51DeRE4WKsEt2pFZiQCpxmoDgSBu51niqftKU7KTHrxB7v1+COLu4WMiPxC5X6HNE2LfXZlPEjRL2IDBsR1u/d7q7wY8I567R7XCmL7ZFX6ZLgYRsw0IQxMNB39QhEU0Bfjv0rPlWIhpUxW8LgRTAQcp2DXEewAFfFpIIhCAtehBZQbzY/UGiB9qpe89NCALJ+sNjmzcLqU241h+sv5xJCDTf033Js//VXLkKfs5NA== Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2 ECDHE-RSA AES-256-GCM AEAD) via TCP6; 08 Dec 2020 02:37:45 -0000 Received: by ary.qy (Postfix, from userid 501) id 9DD5F2925ED5; Mon, 7 Dec 2020 21:37:44 -0500 (EST) Date: 7 Dec 2020 21:37:44 -0500 Message-Id: <20201208023744.9DD5F2925ED5@ary.qy> From: "John Levine" To: dmarc@ietf.org Cc: blong@google.com In-Reply-To: Organization: Taughannock Networks X-Headerized: yes Cleverness: minimal Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] Ticket #39 - remove p=quarantine X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 08 Dec 2020 02:37:49 -0000 In article you write: >Anyways, +1 to keeping p=quarantine as a concept, but willing to go along >with the consensus on naming. I'm modestly in favor of keeping p=quarantine as a feature but utterly opposed to changing the keywords such as "p=quarantine" in the DMARC record. It's fine to improve the text in the RFC that describes what they mean but let us please not make gratuitously incompatible changes. R's, John From nobody Mon Dec 7 19:16: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 E59333A0DC6 for ; Mon, 7 Dec 2020 19:16:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.851 X-Spam-Level: X-Spam-Status: No, score=-1.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iecc.com header.b=IV2wJMzD; dkim=pass (2048-bit key) header.d=taugh.com header.b=Ub8Yi94C Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9ERzyIVLIlQV for ; Mon, 7 Dec 2020 19:16:14 -0800 (PST) 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 506DB3A0DC4 for ; Mon, 7 Dec 2020 19:16:13 -0800 (PST) Received: (qmail 87300 invoked from network); 8 Dec 2020 03:16:10 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:mime-version:content-type:content-transfer-encoding:cleverness; s=15500.5fceeffa.k2012; bh=D3MPxphFc6lgC2y/4EFDkyrLS2pHsl/wFJwYjJl+E2M=; b=IV2wJMzDgf1QqHk3wvLQ8pFs/Jza0FTCGfDH5Z54OoGiBIFVhJQsxC/T2w92ascVjzS8NJyo8v4f5vhztfhH55JtfGx7ij/wjegs3BLWcVFKHxnD37ZhD3E2yqcU7bwvU4DM/dpEEvbdY2tvkMsiYRoaF6uAA8WMQOcLuJvQk0cyXJP97MXGBurU1TBxHNrLiOJiZaQrk37GpKDm+PDKoGtwcIHbqLmzET5DB8lbMjcXJijBBLGZX9mCOSJUhc048benmP8/nFMdtFH73SHRg4993w/QnaWVV/17zoxBzKnzIGimT6desWeQ0hAvfo2xHh6Cc7TVhkMW/HusyxATcw== DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:mime-version:content-type:content-transfer-encoding:cleverness; s=15500.5fceeffa.k2012; bh=D3MPxphFc6lgC2y/4EFDkyrLS2pHsl/wFJwYjJl+E2M=; b=Ub8Yi94CNcM97g2Ue2Nga0Gn6zg80dMJZkqM8/0qBPZs3rzsStDLkSsMiEFyj9diW9vDcgNCaUEn+WQtY2ocPlYkPPeWPV3h3WZnqpxwRKm4z+KWIE5oVY8EomMNAIOSKJxVWx3PCshunLAa+4zFx+T+vamGzB0z5xqL/80b8d0/7dfKDq9s6b3Nq9EaTGl7QF1ib1A0csunP5qDcmPMshurWrCc8FhSbuiAM+EbK0DQLJBdcoxnnsBeH+N18WBtXHdswz4leXJqrVDxfoZk9j2N+bg+bHnZ5Hkrer0RDr04Nyghw8SjPxgqu0nv4ZRG2Jf9KkxkxCB8o/SR5JoKfg== Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2 ECDHE-RSA AES-256-GCM AEAD) via TCP6; 08 Dec 2020 03:16:10 -0000 Received: by ary.qy (Postfix, from userid 501) id C8CC52926414; Mon, 7 Dec 2020 22:16:09 -0500 (EST) Date: 7 Dec 2020 22:16:09 -0500 Message-Id: <20201208031609.C8CC52926414@ary.qy> From: "John Levine" To: dmarc@ietf.org Organization: Taughannock Networks X-Headerized: yes Cleverness: minimal Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] A-R results for DMARC X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2020 03:16:16 -0000 I don't think there is a ticket for this, but it would be nice if there were standard ways to put a few more items into the DMARC part of an A-R header, in particular the p= and pct= values and the location of the policy record if it's not the same as header.from. None of the existing ptypes really apply here (in particular "policy" is for local policy, not a policy you found somewhere else.) Perhaps call it polrec for policy record and add polrec.p polrec.pct and polrec.domain. I have never understood all of the indirection involved in defining stuff for A-R but I'm hoping Murray can help out. R's, John From nobody Mon Dec 7 19:20: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 496673A0DD7 for ; Mon, 7 Dec 2020 19:20:13 -0800 (PST) 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 2jL1jLzi7xI9 for ; Mon, 7 Dec 2020 19:20:11 -0800 (PST) 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 2E69C3A0DCB for ; Mon, 7 Dec 2020 19:20:11 -0800 (PST) Received: by mail-ua1-x92f.google.com with SMTP id f29so2945036uab.0 for ; Mon, 07 Dec 2020 19:20:11 -0800 (PST) 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=VEmqUJkXK8YS/TyJcYswgaUMJUyQ4PHPbf6fWCHjYRU=; b=LCEEI0aTADbxs9C8umRvVxCC8QkLezq6g86BrJQrTV5cROGaUZxlRwGG1o1bAJspTe /fUmJi3dLntj/aCI+vVW1bdppwsYOXMkDaRoKFE6s9/Q3s623j6XIWKpgwVnzUC6DERV XDgMc1+hNIM9wE0DJj9Pv1dcpZCtUJygIuSV6pFwF+B/g86rLpBTudLn3nKnte80A8AT Vwht5SL5j/6QqEZX23e9WKg4jmsIUV3tjyEcG0sn/V+7GqluOqU899qvKzQcRnCIH/zw 2y8k3xXogUtpixiiZ6J9YZpzLKqHpscri2oGl3zUTHqoz7m/jeVdWD8WQRBsaoAWRSPA H92A== 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=VEmqUJkXK8YS/TyJcYswgaUMJUyQ4PHPbf6fWCHjYRU=; b=pBz2o46sAVagYfk03BN0JFZYs/6RR5NPXnAL4bxaOrhg7bjp6T1C+aHjsV++6NC8Mr tkgMYZSlhPYPKFtWVHMk2dvrUn0wwRety68lZqPPn5v8vQtN1ld4y1Oo0zMartGfNSY6 Lqlb46EkWT6BjoagtBMv2JYy4QsMCmvko1hrDxWhAIuVKK7AOkFvQ2d0vKB5tSJW+TIJ PfuRPVQE5ss7MzBMtytPpKLsQ94FwbApI3MI1zFzzOvsa0i9VMC74AafJncTS+2mnm6h smfLWPyLVwQJ3d3jUdovG62OmMqEZLEJgdeOesbRqcsd1sT11QKpv95unKc8h0BRMTdM R/qQ== X-Gm-Message-State: AOAM533E7taa3sDqwfaMnz3S+c2YeRmcRCJzfPT6WJLsJEU/KjykvCYo 9t7/lHiTw1bISPDHNjQ46YVjoVqfrUWAQhF6UGQ/jT9Gs3c= X-Google-Smtp-Source: ABdhPJxf7tSICuzfRoJG2yNoQ9GCWij5hYOm9Ipuqd7OLoRiYdp6dC866yap1Rr2tAP9+mtqI5nz3l//SLVb2jmJaLM= X-Received: by 2002:ab0:67d4:: with SMTP id w20mr13934453uar.47.1607397610050; Mon, 07 Dec 2020 19:20:10 -0800 (PST) MIME-Version: 1.0 References: <20201208031609.C8CC52926414@ary.qy> In-Reply-To: <20201208031609.C8CC52926414@ary.qy> From: Seth Blank Date: Mon, 7 Dec 2020 19:19:59 -0800 Message-ID: To: John Levine Cc: dmarc@ietf.org Content-Type: multipart/alternative; boundary="0000000000008f68e105b5eb6bca" Archived-At: Subject: Re: [dmarc-ietf] A-R results for DMARC X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2020 03:20:13 -0000 --0000000000008f68e105b5eb6bca Content-Type: text/plain; charset="UTF-8" Please open a ticket, agreed that standardization here is a good thing. I have some further thoughts as an individual once the ticket is opened. On Mon, Dec 7, 2020 at 19:16 John Levine wrote: > I don't think there is a ticket for this, but it would be nice if > there were standard ways to put a few more items into the DMARC part > of an A-R header, in particular the p= and pct= values and the > location of the policy record if it's not the same as header.from. > > None of the existing ptypes really apply here (in particular "policy" is > for local policy, not a policy you found somewhere else.) Perhaps call > it polrec for policy record and add polrec.p polrec.pct and polrec.domain. > > I have never understood all of the indirection involved in defining > stuff for A-R but I'm hoping Murray can help out. > > R's, > John > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > -- *Seth Blank* | VP, Standards and New Technologies *e:* seth@valimail.com *p:* 415.273.8818 This email and all data transmitted with it contains confidential and/or proprietary information intended solely for the use of individual(s) authorized to receive it. If you are not an intended and authorized recipient you are hereby notified of any use, disclosure, copying or distribution of the information included in this transmission is prohibited and may be unlawful. Please immediately notify the sender by replying to this email and then delete it from your system. --0000000000008f68e105b5eb6bca Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Please open a ticket, agreed that standardization here is= a good thing.

I have so= me further thoughts as an individual once the ticket is opened.
<= br>
On Mon,= Dec 7, 2020 at 19:16 John Levine <jo= hnl@taugh.com> wrote:
I don't think th= ere is a ticket for this, but it would be nice if
there were standard ways to put a few more items into the DMARC part
of an A-R header, in particular the p=3D and pct=3D values and the
location of the policy record if it's not the same as header.from.

None of the existing ptypes really apply here (in particular "policy&q= uot; is
for local policy, not a policy you found somewhere else.)=C2=A0 Perhaps cal= l
it polrec for policy record and add polrec.p polrec.pct and polrec.domain.<= br>
I have never understood all of the indirection involved in defining
stuff for A-R but I'm hoping Murray can help out.

R's,
John

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

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


<= /p>

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

--0000000000008f68e105b5eb6bca-- From nobody Mon Dec 7 19:20: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 5B29E3A0E2C for ; Mon, 7 Dec 2020 19:20:32 -0800 (PST) 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 NEcKz_JA0vgF for ; Mon, 7 Dec 2020 19:20:30 -0800 (PST) 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 9FC723A0E23 for ; Mon, 7 Dec 2020 19:20:30 -0800 (PST) Received: by mail-vs1-xe35.google.com with SMTP id v8so8833043vso.2 for ; Mon, 07 Dec 2020 19:20:30 -0800 (PST) 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=O7Gyaett9f4KoVdDPd0ZMZLuObHz62ka+y7au9BhMEQ=; b=ZKv28nwoqRxgHVVOK58JDDAPLs6xn1SGUsKJHfdBW00yvSgyu8JgyR5Vyl+n5Q0Tto 47atXd9IZWN+G+50u1Vimmt4QUw3PWf2uRNLOyTKUbbAfkz+u9wwbsMIqaKFH3OHaEc7 U/4Dug4Ff/OIQaKeK7RxCWss9QLZFg79mzajBPG1dfyA8Mhr7Gtq21GINMkO/EGCHUEO wXmc7g7EGmjCgc1UKBYIVRHWiVoy6V+lDHDg0S2us6cTG9O4Ru6BQeW9LnJq7rhvwcP+ /UNeUENBl9QX4X6CZZU2UoBA0u65eoe8NrnStflVLuN//SmvpIvx+LO+yruyKrnGzhLP F8bA== 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=O7Gyaett9f4KoVdDPd0ZMZLuObHz62ka+y7au9BhMEQ=; b=hcWOiSzwQXdGL1/pai1Sy6m5P1r4RziS9mcNLHb7kvgxT7EpQIGs1ib/bPxXQ2TUSV FzTNYzWXyEbALxBBF1TTr+1dpMVEnYrZAuG4mLyH+H7wn6L+x955EGIzJhUura6ZvuOp SBVMTmUcrXSyp1fA6RvJzNY4dGKU9YV4ThpHY+AMLHDRcIb0EjMuEt6I/hBYIAmpgP64 zNkEfk3GoTW+UE3lCvgCmal5Wv56gojaER2N6FWrvdi6W0KUDXfk8wKXry/yi9y4oUHN MA5Nsl+iF6wrmBlRNEAr50RicgDLMQ5Csc2NpQEGs8/ZglnKpeS6WBUQflZggKc8J8O4 aunQ== X-Gm-Message-State: AOAM5320Syr9n/ZOH1SeqxoDOERaZ3C8n6WEv15RTXr8myRy7Fpo1pKI kmccO7qJNWfwqnCENfEQCibINMGUtABqI+UbSmE= X-Google-Smtp-Source: ABdhPJxag2Zh0p222xAHRik39oPMxHyXsnujPbobnm4NBA5jvgl8MjV/1bi8VIAyN6IaREflOoy4CHgOMg6Rh294krQ= X-Received: by 2002:a67:ed19:: with SMTP id l25mr14935010vsp.59.1607397629764; Mon, 07 Dec 2020 19:20:29 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Douglas Foster Date: Mon, 7 Dec 2020 22:20:16 -0500 Message-ID: To: Dotzero Cc: "Murray S. Kucherawy" , IETF DMARC WG , John R Levine Content-Type: multipart/alternative; boundary="000000000000bc2acc05b5eb6c34" Archived-At: Subject: Re: [dmarc-ietf] Ticket #1 - SPF alignment X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 08 Dec 2020 03:20:34 -0000 --000000000000bc2acc05b5eb6c34 Content-Type: text/plain; charset="UTF-8" Is there an identifiable attack vector which can be based on using the (forward confirmed) HELO name for SPF pass? If not, why change? On Mon, Dec 7, 2020, 6:09 AM Dotzero wrote: > > > On Mon, Dec 7, 2020 at 2:13 AM Murray S. Kucherawy > wrote: > >> On Tue, Dec 1, 2020 at 2:17 PM John R Levine wrote: >> >>> We would like to close this ticket by Dec 15, two weeks from now, so >>> short >>> trenchant comments are welcome. >>> >>> Ticket #1 is about SPF alignment. We need to replace references to 4408 >>> with 7408, ando clarify what if anything we do with SPF HELO checks if >>> the MAIL FROM is null. One possibility is to say only MAIL FROM SPF >>> counts, if you want to align your bounces, sign them. The other is to >>> explicitly say that HELO alignment is OK on bounces. >>> >> >> I have a slight preference for the first option. HELO is too arbitrary >> in the protocol for me to put much value in using it in any of these >> systems. >> >> -MSK >> > > +1 > > Michael Hammer > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > --000000000000bc2acc05b5eb6c34 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Is there an identifiable attack vector which can be based= on using the (forward confirmed) HELO name for SPF pass?
=
If not, why change?



=
On Mon, Dec 7, 2020, 6:09 AM Dotzero = <dotzero@gmail.com> wrote:

On Mon, Dec 7, 2020 at 2:13 AM Murray S. Kucherawy <superuser@gmail.c= om> wrote:
On Tue, Dec 1, 2020 at 2:17 PM John R L= evine <johnl@taugh.com> wrote:
<= 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">We would like to close thi= s ticket by Dec 15, two weeks from now, so short
trenchant comments are welcome.

Ticket #1 is about SPF alignment.=C2=A0 We need to replace references to 44= 08
with 7408, ando clarify what if anything we do with SPF HELO checks if
the MAIL FROM is null.=C2=A0 One possibility is to say only MAIL FROM SPF <= br> counts, if you want to align your bounces, sign them.=C2=A0 The other is to=
explicitly say that HELO alignment is OK on bounces.
<= br>
I have a slight preference for the first option.=C2=A0 HELO i= s too arbitrary in the protocol for me to put much value in using it in any= of these systems.

-MSK

+1

Michael Hammer
<= /div>
_______________________________________________
dmarc mailing list
dmar= c@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
--000000000000bc2acc05b5eb6c34-- From nobody Mon Dec 7 20:19: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 F35B33A0DFA for ; Mon, 7 Dec 2020 20:19:08 -0800 (PST) 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 mEsWRxz-unkH for ; Mon, 7 Dec 2020 20:19:07 -0800 (PST) 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 1A3953A0DAD for ; Mon, 7 Dec 2020 20:19:07 -0800 (PST) Received: by mail-ua1-x92d.google.com with SMTP id y21so5255302uag.2 for ; Mon, 07 Dec 2020 20:19:07 -0800 (PST) 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=Z/xi3dFyvmDhL1YU6/4fePrHldkXQZEny4s6ptZbNEE=; b=BhgLIf2I5iVehHgiTb3DJfyDWKQ192oRfcQc0rIsguHGPCw8ri4T3V6bJ0NCxvNVc8 qRJ1++AOPoEjwtxOcGJ7w5TcPg2OLfnR/ONYsTDnZHMFwonUAdiamui0blIEUcR5xKD4 M7+bU5wQHyU4Uk9u0LBvKxZ9ao0VUmzHWEym4PpUIun9TZU+6PqTz7IfW4t4po4cuj6N O3VobpVKfsLTepGB94eDbWNjH70YL+5RMV/Bjgtg5GFoQJEYgTi6s4fuPvabUGwjXzWU NkEiLZkAn4rT3YnFI9l9lVf9T+fG70f7MjWEoRkjKZSYVQs0+RvI6dDTLd6mMTyCDVh5 qMWQ== 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=Z/xi3dFyvmDhL1YU6/4fePrHldkXQZEny4s6ptZbNEE=; b=oBCoYZlvq9fW/9xJXsDEyEjrAQLBZkSbyvxG3hEUtKX0P+3of4bhGuOrModv2WZMq1 Bm5ESASCiQAmZwoX3r9/Ys4sBjn1KpJi+ZDBvQd/jxAF8T5pqaDArlUs/KyFE7AXxBRo 1zj9WrZGoUGTuzld53IBQEOYPs4EKl3bjFcHUDtJD4COo186JoYkla+bZ0iqQEcDXxSh aMFmwV6uwqjAYO1QKQF8JI7hSiSTdgtagvqQUTjBJ7IxWSaVJNNh8yE0Wz0qybumUW3v pvnJobM25oGSG6HVkI99JTckmYEFbZw+tIcxUG7dD9jToJqnbE72kNSxeBeOQ/eQ5tlr ef7g== X-Gm-Message-State: AOAM5339a051+dyifOBNXJMbZNFRdSh7hMUB1yshwNYvr00NleTQKF8e TQZE71/wpyOdlc/AhthrOrh4b666hkG1zg8XOGa8aUyK X-Google-Smtp-Source: ABdhPJz4uBr2/fhUaCJqlUEzVrtyhYzuGktYd/TY6Oz/e+wcYUigqgq/vLEcpEH6Xv+BdPEa8F648m69YHK3aTjEgN4= X-Received: by 2002:ab0:2e9:: with SMTP id 96mr14063408uah.87.1607401145927; Mon, 07 Dec 2020 20:19:05 -0800 (PST) MIME-Version: 1.0 References: <20201208031609.C8CC52926414@ary.qy> In-Reply-To: <20201208031609.C8CC52926414@ary.qy> From: "Murray S. Kucherawy" Date: Mon, 7 Dec 2020 20:18:54 -0800 Message-ID: To: John Levine Cc: IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000508e7105b5ec3ee1" Archived-At: Subject: Re: [dmarc-ietf] A-R results for DMARC X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2020 04:19:09 -0000 --000000000000508e7105b5ec3ee1 Content-Type: text/plain; charset="UTF-8" On Mon, Dec 7, 2020 at 7:16 PM John Levine wrote: > I have never understood all of the indirection involved in defining > stuff for A-R but I'm hoping Murray can help out. > What I think you're referring to is a distinction between the way we seem to want to use A-R now versus how it was originally intended. The original intent back in RFC 5451 was to relay only those details that an MUA might care about, such as the DKIM result (so you can display something representing a "pass" or "fail" on a message) and maybe the domain name found in a passing signature (an early shot at caring about alignment when rendering a message). The community seems to have shifted toward that being too strict and instead wanting to use it as a transport mechanism for any evaluation detail about the message that might be interesting to the MUA or any other downstream agent once it reaches its final ADMD. RFC 8601, for instance, registered "header.a" and "header.s", DKIM properties that are almost certainly of no interest to MUAs. So that ship has sailed, meaning yes, we could register these too if they're going to be useful to downstream agents. Though for that matter, you could just start using them even without registering them to see if it would be helpful, because 8601 allows for local conventions (the tried-and-true "ignore what you don't know" thing that DKIM introduced). -MSK --000000000000508e7105b5ec3ee1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I have never understood all of the indirection involved in defining=
stuff for A-R but I'm hoping Murray can help out.
=
What I think you're referring to is a distinction betwee= n the way we seem to want to use A-R now versus how it was originally inten= ded.

The original intent back in RFC 5451 was to r= elay only those details that an MUA might care about, such as the DKIM resu= lt (so you can display something representing a "pass" or "f= ail" on a message) and maybe the domain name found in a passing signat= ure (an early shot at caring about alignment when rendering a message).=C2= =A0 The community seems to have shifted toward that being too strict and in= stead wanting to use it as a transport mechanism for any evaluation detail = about the message that might be interesting to the MUA or any other downstr= eam agent once it reaches its final ADMD.=C2=A0 RFC 8601, for instance, reg= istered "header.a" and "header.s", DKIM properties that= are almost certainly of no interest to MUAs.

= So that ship has sailed, meaning yes, we could register these too if they&#= 39;re going to be useful to downstream agents.=C2=A0 Though for that matter= , you could just start using them even without registering them to see if i= t would be helpful, because 8601 allows for local conventions (the tried-an= d-true "ignore what you don't know" thing that DKIM introduce= d).

-MSK
--000000000000508e7105b5ec3ee1-- From nobody Mon Dec 7 20:31: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 690F53A0E02 for ; Mon, 7 Dec 2020 20:31:23 -0800 (PST) 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 (2048-bit key) header.d=iecc.com header.b=sJdBulOG; dkim=pass (2048-bit key) header.d=taugh.com header.b=lQYHNeWJ Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P4t1dAG-_n_H for ; Mon, 7 Dec 2020 20:31:21 -0800 (PST) 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 7EB9C3A0DFC for ; Mon, 7 Dec 2020 20:31:21 -0800 (PST) Received: (qmail 99376 invoked from network); 8 Dec 2020 04:31: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; s=1842e.5fcf0196.k2012; i=johnl-iecc.com@submit.iecc.com; bh=ZwvF0oMw62Dk2eQo30VLUbXhgmfPKB4cCUofryWfklM=; b=sJdBulOGQUIfxfTw61+jgKKtOnBNPSPADqEiXtKAFihVw0icWqpMINQRN5ehd5yDcmSt5AmmG+iExwPUXqCFIIf1Jqv0Q26NpC5/Xh+vl5m70Kn+IyqrYTa1gyhSdmF0rtnhvB6Sw8h3hGxDHHnmep2Fj4xXzSlc0Aofn/lq6EcuwA6xOOxhHoH8kfdwVEagyenFluayS6oyzYba1+bI4kjMuaqwObac/KnjagKIoXPJf34CNKnk791ZyeKGOaia50qPeKNGQWuV7k72Kx7RazGzdt7/V9OJSL+zhmKsFk52RZJGFf6m7uNJgYWf4vKSo9pfsqKu4kZ7I2gjC/83mg== 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=1842e.5fcf0196.k2012; olt=johnl-iecc.com@submit.iecc.com; bh=ZwvF0oMw62Dk2eQo30VLUbXhgmfPKB4cCUofryWfklM=; b=lQYHNeWJlhSmikYYx/KXc1K9ATC3hR8UZyWEehQ4SoPv5HY5JjEs1o8lNLCFSR4eF6vYxYk+uIsmSAR/UlLFuZ4+eSoAIUqNwjljdS837n21BcPolIjh03Xokq6az74IZeMLH6JmNd++ymJAqIfwPPZw6IkmM0/IQwwV/PX+TlXgRX3ww7EntNnS1fPB0klfY8MXK7M8GBY7a6ZRwaDgaC49Wpl5PilYIWWNWgvlT27bzAkwBHmtVtVFNxiyHHqD87YlskooBMRClATEozewAwkDP2lnF0t/lajqSaWu4j6Sz4UOd7RYWoYekMzp0TNl5KW+bOdYJjskYEHdKF4+YQ== 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; 08 Dec 2020 04:31:18 -0000 Date: 7 Dec 2020 23:31:17 -0500 Message-ID: From: "John R Levine" To: "Murray S. Kucherawy" Cc: "IETF DMARC WG" In-Reply-To: References: <20201208031609.C8CC52926414@ary.qy> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [dmarc-ietf] A-R results for DMARC X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2020 04:31:24 -0000 On Mon, 7 Dec 2020, Murray S. Kucherawy wrote: > The original intent back in RFC 5451 was to relay only those details that > an MUA might care about, such as the DKIM result (so you can display > something representing a "pass" or "fail" on a message) and maybe the > domain name found in a passing signature (an early shot at caring about > alignment when rendering a message). ... I suppose but 5451 also says it might be useful to message filters. > So that ship has sailed, meaning yes, we could register these too if > they're going to be useful to downstream agents. Though for that matter, > you could just start using them even without registering them to see if it > would be helpful, because 8601 allows for local conventions (the > tried-and-true "ignore what you don't know" thing that DKIM introduced). Sure, I can write the code to stick them in but it would be nice to have some expectation that I'm not going to collide with something else, or other people use different tags for the same thine. 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 Dec 8 03:24: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 F415C3A0BF5 for ; Tue, 8 Dec 2020 03:24:53 -0800 (PST) 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, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (4096-bit key) header.d=aegee.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HTmBjtkNXxdv for ; Tue, 8 Dec 2020 03:24:50 -0800 (PST) Received: from mail.aegee.org (mail.aegee.org [144.76.142.78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3FE73A0BF0 for ; Tue, 8 Dec 2020 03:24:49 -0800 (PST) Authentication-Results: mail.aegee.org/0B8BOQjL767092; auth=pass (LOGIN) smtp.auth=didopalauzov@aegee.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=aegee.org; s=k4096; t=1607426675; i=dkim+MSA-tls@aegee.org; bh=+n7FwivVD5rW1Js48OYwrp+1QgIKj/fU4wOSpqUnHG0=; h=Subject:From:To:Cc:Date:In-Reply-To:References; b=IJTagKFN/gu17qlYGRKqz8wv/44YQJj/cQzlXRao/iU3IEn+6S1qXRWvLnCvyvIC+ 7NdYbs43v1FisYpRGJoEn4lexUXGp4ee4MujNVgnfPA61DWxt7Y0BijqeEhQaxpLl9 hUg4pJjj+qK+FxsBWy0pnuoWJVv7Vi6j+4q+UiBhKRIrPsr9ZDTqIzG0VNjyXkaECu iymADzrnMdsILjcipO/BFa35r7ZHk+hGNYiXQzcSNa0U091IqL2u3Wk3qCk5/rC7es 5SR2wVjlf6Qp1nhbY1Vm0oSzRsjEvMUD9textkqx6rO3dLPR5TA7PQNii08tJRL6lW lLdpUQHCs2ghv2UJC8072FO1Q7tB2Exb3h7Z/JGrHSFHFt/UpY10EqDAsg1G5mO07u CRuiJjZmJZ9N8x8C5WUjTkWCBTkLNNUWCd0s1pD8B2XoyQaqlQqkUkc3DtguzhPWm0 0wzv5GGjb5vsJrUgvfVDDChv8z93hWTaBKEZ2PhHhc/Pu+X2MNCDWkgLvwZd9ks3W/ sdsYAlbRnT4lScFFcUR3hRJrPTIfGf/Uh7KotazMLBwEWO7/oCNMDHGCDtlnX5sp9u NLIDK0Z+TqGlUE/TUWpr6mjFM8TrCfF8lDo2cPKo+lPRdZjHjMmRXBt4DJWPWUees2 iI/UNJB856xa3HQihlk0FE/s= Authentication-Results: mail.aegee.org/0B8BOQjL767092; dkim=none Received: from [192.168.1.99] (87.118.146.153.topnet.bg [87.118.146.153] (may be forged)) (authenticated bits=0) by mail.aegee.org (8.15.2/8.15.2) with ESMTPSA id 0B8BOQjL767092 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Tue, 8 Dec 2020 11:24:27 GMT Message-ID: <1ddcc797fb34a9d45b9467a7a86c49751e013561.camel@aegee.org> From: =?UTF-8?Q?=D0=94=D0=B8=D0=BB=D1=8F=D0=BD_?= =?UTF-8?Q?=D0=9F=D0=B0=D0=BB=D0=B0=D1=83=D0=B7=D0=BE=D0=B2?= To: Brandon Long , "Murray S. Kucherawy" Cc: IETF DMARC WG , Dotzero , Benny Lyne Amorsen Date: Tue, 08 Dec 2020 13:24:24 +0200 In-Reply-To: References: <20201202021651.E8EE128C576A@ary.qy> <327860af-2fa7-63ee-4b89-6e7e383f3d53@crash.com> <2804da89-84d1-f601-9425-0b0d9baf6ae1@gmail.com> <1f6cae74-4eed-47f5-7249-e526bf1f5845@crash.com> <87y2ig9t9i.fsf@orion.amorsen.dk> Content-Type: multipart/alternative; boundary="=-jz9tM/IdWIEWr2u/ytDj" User-Agent: Evolution 3.39.1 MIME-Version: 1.0 Archived-At: Subject: Re: [dmarc-ietf] Ticket #39 - remove p=quarantine X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 08 Dec 2020 11:24:54 -0000 --=-jz9tM/IdWIEWr2u/ytDj Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit Hello, I do no see the point of having all the discussions here, as nobody is capable to read and understarstand all written emails in their whole quantity.  I personally do not follow the discussions anymore, apart from reading the subjects… On Mon, 2020-12-07 at 17:55 -0800, Brandon Long wrote: > > > On Wed, Dec 2, 2020 at 11:09 AM Murray S. Kucherawy > wrote: > > On Wed, Dec 2, 2020 at 6:47 AM Dotzero wrote: > > > p= DID NOT mistakenly choose to use the language of receiver > > > actions. p= represents the domain-owner request to the receiver > > > as to the disposition of messages which fail to validate. Any > > > reading of "concern" is supposition on the part of yourself or > > > other self appointed interpreters of the mind of the domain-owner > > > or administrator. The vocabulary is perfectly fine as it > > > accurately describes the request being made. It makes no attempt > > > to read the underlying reasoning behind the request because, > > > surprisingly, there is likely to be a wide range of underlying > > > reasoning behind why various domains publish the policies they > > > publish. This is an interoperability standard, not a seance. > > > > > > > > > Not sure I agree. > > > > I have long held a quiet dislike for "quarantine" because that has > > a particular meaning to milter implementations.  Specifically, > > milter can render one of several final results about a message, one > > of which is actually called "quarantine".  It means "park this in > > the queue indefinitely until a human decides what to do with it."  > > There's no indication to the operator that such a job is waiting > > for review unless one goes and looks for such things.  The upshot > > of this is that quarantining in that environment can become a > > denial of service attack if I send you enough messages that end up > > getting handled that way and your queue disk fills, or the queue > > takes an inordinately long time to process because these have piled > > up and need to be inspected. > > > > Certainly not all implementers will trip on this (maybe none will) > > but it's an argument to me in favor of picking a word or set of > > words that describe what the domain owner thinks of the message, > > rather than what the domain owner thinks you should do with it. > > > > > Hmm, reading this thread, I think one missing feature in the dmarc > spec is passing the expected disposition in the authres header, since > presumably the evaluation is at smtp time, but the mailbox > delivery itself would need to know it.  One could use the dmarc= > names and look up the dmarc policy itself to also figure that out > with some amount of work. … and in July 2019 there was a discussion with the subject „Reporting DMARC policy in A-R header fields“ on this mailing lists.    Below is an off-list consensensus to put the applied policy in the A-R from that thread, that was not sent eventually over the mailing list: From: Scott Kitterman To: Дилян Палаузов Subject: Re: Reporting DMARC policy in A-R header fields Date: Wed, 31 Jul 2019 10:49:32 +0000 I agree with your statement.  MTA does the percentage test and puts the policy to be applied in A-R for the MDA to consume. I'm working off my phone, so typing is slow.  I don't mind being more verbose once I'm at my laptop, but it will have to wait.  Please let me know if it's still uncertain. Scott K On July 31, 2019 10:35:15 AM UTC, "Дилян Палаузов" wrote: >Hello Scott, > >you are too spare in your words. > >My understanding of the conversation so far is that only the MTA does >the sampling for failed messages based on p= and >pct= . The A-R header is supposed to carry information, whether the >message validated or failed DMARC and for failed >validation, what the MDA shall do with the message (basically >quarantine or deliver). > >If you put the policy to be applied in the A-R, then it is not the >policy from DNS, but rather the disposition to be >applied. > >Regards >  Дилян > >On Wed, 2019-07-31 at 10:28 +0000, Scott Kitterman wrote: >> I suppose you could also add something like dmarc.pct=50 too, but I >think that would add complexity to no benefit.  As long as you make the >sample decision once, it works out the same.  For the case where a >message wasn't selected due to sampling then I'd put the policy to be >applied in A-R so the MDA doesn't have to worry about the percentage. >>  >> Scott K >>  >> On July 31, 2019 5:56:26 AM UTC, "Дилян Палаузов" > wrote: >> > Hello Scott, >> >  >> > for p=quarantine; pct=50 if the MTA does the sampling and decides >to >> > quarantine, and forward the email to the MDA, how can the MDA know >> > whether it shall quarantine the message or not? >> >  >> > Regards >> >  Dilyan >> >  >> > On July 31, 2019 1:25:23 AM GMT+03:00, Scott Kitterman >> > wrote: >> > > Since the status is per message, I think the MTA should do it and >> > other >> > > than as perhaps a comment, it doesn't need to be in A-R. >> > >  >> > > Scott K >> > >  >> > > On July 30, 2019 2:04:28 PM UTC, "Дилян Палаузов" >> > > wrote: >> > > > OFF LIST >> > > >  >> > > > Hello Scott, >> > > >  >> > > > does the PCT value belong to the published policy and subject >to >> > > > inclusion in the A-R header? >> > > >  >> > > > Who is supposed to apply the sampling, based on PCT parameter: >the >> > > MTA, >> > > > the MDA or both? >> > > >  >> > > > If both are supposed to do it, can the A-R header be extended >in such >> > > a >> > > > way, that only the MTA does the sampling, and >> > > > carries the information to the MDA? >> > > >  >> > > > Regards >> > > >  Дилян >> > > >  >> > > > On Tue, 2019-07-30 at 13:56 +0000, Scott Kitterman wrote: >> > > > > The published policy (that's why I suggest dmarc.policy).  >I'm not >> > > > sure if disposition belongs in A-R.  If it does, it'd be a >local >> > > policy >> > > > override, probably policy.dmarc as described now in RFC 8616. >> > > > > Scott K >> > > > >  >> > > > > On July 30, 2019 1:34:46 PM UTC, "Дилян Палаузов" >> > > > wrote: >> > > > > > Hello Scott, >> > > > > >  >> > > > > > do you want to include in the A-R header the published >policy, as >> > > > > > obtained from DNS (my first interpretation of your >> > > > > > proposal), or the disposition of the message after applying >> > > > > > DKIM/SPF/DMARC validation, pct sampling, and the ominous >> > > > > > reject→quarantine sampling conversions? >> > > > > >  >> > > > > > With disposition I mean what is called at >> > > > > > https://tools.ietf.org/html/rfc6591#section-3.2.2 >> > Delivery-Result. >> > > > > > For the disposition on p=reject only the MTA can make the >> > decision >> > > > > > based on pct to reject, so it makes sense if the >> > > > > > result of disposition is included in the A-R header by the >MTA >> > and >> > > > > > consumed by the MDA.  In turn, including pct and >> > > > > > published DMARC policy in the A-R header, so that the MDA >can do >> > > > the >> > > > > > sampling, does not make sense. >> > > > > >  >> > > > > > If you want to call the new parameter “policy”, then it >shall be >> > > > > > articulated that it means disposition, and not >> > > > > > published policy. >> > > > > >  >> > > > > > I am in favour of the proposal. >> > > > > >  >> > > > > > It allows for forwarded emails/aliases to indicate in the >A-R >> > > > header, >> > > > > > that sampling was already performed by the >> > > > > > aliasing server, and the final server that accepts the >email can >> > > > skip >> > > > > > performing the sampling again.  Performing the >> > > > > > sampling again has the disadvantage, that the pct= >parameter is >> > > > > > misinterpreted, as the parameter is supposed to be >> > > > > > applied only once. >> > > > > >  >> > > > > > On the other side, skipping of the second sampling by >whatever >> > > > server >> > > > > > is pure theory, and has no practical impact. >> > > > > >  >> > > > > > Greetings >> > > > > >  Дилян >> > > > > >  >> > > > > > On Tue, 2019-07-30 at 00:54 -0400, Scott Kitterman wrote: >> > > > > > > On Monday, July 29, 2019 3:37:55 PM EDT Scott Kitterman >wrote: >> > > > > > > > I'd like to add the option to record DMARC results in >an A-R >> > > > header >> > > > > > field >> > > > > > > > for consumption by a downstream processor.  I think it >would >> > > be >> > > > > > something >> > > > > > > > like this: >> > > > > > > >  >> > > > > > > > Authentication-Results: mail-router.example.net; >dmarc=pass >> > > > > > > > header.from=example.com policy.dmarc=none >> > > > > > > >  >> > > > > > > > That would take adding an entry in the Email >Authentication >> > > > Methods >> > > > > > registry >> > > > > > > > for: >> > > > > > > >  >> > > > > > > > method: dmarc >> > > > > > > > ptype: policy >> > > > > > > > value: dmarc >> > > > > > > >  >> > > > > > > > Does that make sense as a way to do it?  Does anyone >have >> > > > > > alternative >> > > > > > > > suggestions? >> > > > > > >  >> > > > > > > I think comments should be free-form.  If we want data >that can >> > > > be >> > > > > > machine  >> > > > > > > parsed, we should specify it. >> > > > > > >  >> > > > > > > I think the above works in ABNF terms.  It's: >> > > > > > >  >> > > > > > > Authentication-Results:" authserv-id; method=result >> > > > > > ptype.property=value  >> > > > > > > ptype.property=value >> > > > > > >  >> > > > > > > According to the ABNF, there can be more than one >propspec  >> > > > > > > (ptype.property=value) per methodspec in resinfo, so I >think >> > > it's >> > > > > > legal.  It  >> > > > > > > would just need the new registry values for dmarc. >> > > > > > >  >> > > > > > > Scott K >> > > > > > >  >> > > > > > >  >> > > > > > > _______________________________________________ >>  > > I know that Gmail and others put that information in the comments, > but that probably shouldn't be for something explicitly part of the > spec like this. > > Anyways, +1 to keeping p=quarantine as a concept, but willing to go > along with the consensus on naming. > > Brandon  > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc --=-jz9tM/IdWIEWr2u/ytDj Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable
Hello,

I do no see the point of having all the discussions here, as nobody is ca= pable to read and understarstand all written emails in their whole quantity= .  I personally do not follow the discussions anymore, apart from read= ing the subjects=E2=80=A6

On Mon, 2020-12-07 at 17= :55 -0800, Brandon Long wrote:


On Wed, Dec 2, 2020 at 11:09 AM Murray S. Kuchera= wy <superuser@g= mail.com> wrote:
On Wed, Dec 2, 2020 at 6:47 AM Dotzero <dotzero@gmail.com> wrote:<= br>
p=3D DID NOT mistakenly choose to use the language of receiver actions= . p=3D represents the domain-owner request to the receiver as to the dispos= ition of messages which fail to validate. Any reading of "concern" is suppo= sition on the part of yourself or other self appointed interpreters of the = mind of the domain-owner or administrator. The vocabulary is perfectly fine= as it accurately describes the request being made. It makes no attempt to = read the underlying reasoning behind the request because, surprisingly, the= re is likely to be a wide range of underlying reasoning behind why various = domains publish the policies they publish. This is an interoperability stan= dard, not a seance.


Not sure = I agree.

I have long held a quiet dislike for "qua= rantine" because that has a particular meaning to milter implementations.&n= bsp; Specifically, milter can render one of several final results about a m= essage, one of which is actually called "quarantine".  It means "park = this in the queue indefinitely until a human decides what to do with it."&n= bsp; There's no indication to the operator that such a job is waiting for r= eview unless one goes and looks for such things.  The upshot of this i= s that quarantining in that environment can become a denial of service atta= ck if I send you enough messages that end up getting handled that way and y= our queue disk fills, or the queue takes an inordinately long time to proce= ss because these have piled up and need to be inspected.

Certainly not all implementers will trip on this (maybe none will) b= ut it's an argument to me in favor of picking a word or set of words that d= escribe what the domain owner thinks of the message, rather than what the d= omain owner thinks you should do with it.


Hmm, reading this thread, I think one missing feature = in the dmarc spec is passing the expected disposition in the authres header= , since presumably the evaluation is at smtp time, but the mailbox
delivery itself would need to know it.  One could use the dmarc=3D n= ames and look up the dmarc policy itself to also figure that out with some = amount of work.

=E2=80=A6= and in July 2019 there was a discussion with the subject =E2=80=9EReporting DMARC policy in A-R header fields= =E2=80=9C on this mailing lists.    Below is an off-list consense= nsus to put the applied policy in the A-R from that thread, that was not se= nt eventually over the mailing list:

To:=  =D0=94=D0=B8=D0=BB=D1=8F=D0=BD =D0= =9F=D0=B0=D0=BB=D0=B0=D1=83=D0=B7=D0=BE=D0=B2 <" style=3D"white-space:= nowrap;">dilyan.palauzov@aegee.org>= ;
Subject: Re: Repor= ting DMARC policy in A-R header fields
Date: Wed, 31 Jul 2019 10:49:32 +0000
<= br>

I agree with your statement.  MTA does th= e percentage test and puts the policy to be applied in A-R for the MDA to c= onsume.

= I'm w= orking off my phone, so typing is slow.  I don't mind being more verbo= se once I'm at my laptop, but it will have to wait.  Please let me kno= w if it's still uncertain.

Scott K

On July 31, 2019 10:35:15 AM UTC, "=D0=94=D0=B8=D0=BB=D1=8F=D0=BD = =D0=9F=D0=B0=D0=BB=D0=B0=D1=83=D0=B7=D0=BE=D0=B2" <dilyan.palauzov@aegee.org> wrote:
>Hello Scott,
>
>you are too spare in your words.
>
>My understandin= g of the conversation so far is that only the MTA does
>the sampling for failed messages based on p=3D and<= br style=3D"caret-color: rgb(46, 52, 54); color: rgb(46, 52, 54); font-fami= ly: "Source Code Pro"; font-size: 13.333333015441895px;">>pct=3D . The A-R header is supposed to carry = information, whether the
>message valid= ated or failed DMARC and for failed
>va= lidation, what the MDA shall do with the message (basically
>quarantine or deliver).
>
>If you put the policy to be = applied in the A-R, then it is not the
>= ;policy from DNS, but rather the disposition to be
>applied.
>
>Regards
>  = =D0=94=D0=B8=D0=BB=D1=8F=D0=BD
>=
>On Wed, 2019-07-31 at 10:28 +0000, Scott Kit= terman wrote:
>> I suppose you could= also add something like dmarc.pct=3D50 too, but I
>think that would add complexity to no benefit.  As long a= s you make the
>sample decision once, i= t works out the same.  For the case where a
>message wasn't selected due to sampling then I'd put the policy = to be
>applied in A-R so the MDA doesn'= t have to worry about the percentage.
>= > 
>> Scott K
>> 
>>= On July 31, 2019 5:56:26 AM UTC, "=D0=94=D0=B8=D0=BB=D1=8F=D0=BD =D0=9F=D0= =B0=D0=BB=D0=B0=D1=83=D0=B7=D0=BE=D0=B2"
&= gt;<dilyan.palauzov@aegee.org> wrote:<= br style=3D"caret-color: rgb(46, 52, 54); color: rgb(46, 52, 54); font-fami= ly: "Source Code Pro"; font-size: 13.333333015441895px;">>> > Hello Scott,
>> > 
>> &g= t; for p=3Dquarantine; pct=3D50 if the MTA does the sampling and decides
>to
>= > > quarantine, and forward the email to the MDA, how can the MDA kno= w
>> > whether it shall quarantin= e the message or not?
>> > <= /font>
<= font color=3D"#737373" style=3D"font-family: "Source Code Pro"; f= ont-size: 13.333333015441895px;">>> > Regards
>> >  Dilyan
&g= t;> > 
>> > On July 31= , 2019 1:25:23 AM GMT+03:00, Scott Kitterman
>> > <sklist@kitterman.com> wrote:=
>> > > Since the status is per messa= ge, I think the MTA should do it and
>&= gt; > other
>> > > than as = perhaps a comment, it doesn't need to be in A-R.
>> > > 
>> &= gt; > Scott K
>> > > <= /font>
<= font color=3D"#737373" style=3D"font-family: "Source Code Pro"; f= ont-size: 13.333333015441895px;">>> > > On July 30, 2019 2:04:2= 8 PM UTC, "=D0=94=D0=B8=D0=BB=D1=8F=D0=BD =D0=9F=D0=B0=D0=BB=D0=B0=D1=83=D0= =B7=D0=BE=D0=B2"
>> > > <dilyan.palauzov@aegee.org> wrote:
>> > > > OFF LIST
>> > > > 
>= ;> > > > Hello Scott,
>>= > > > 
>> > > &= gt; does the PCT value belong to the published policy and subject>to
>> &g= t; > > inclusion in the A-R header?
= >> > > > 
>> >= ; > > Who is supposed to apply the sampling, based on PCT parameter:<= /font>
<= font color=3D"#737373" style=3D"font-family: "Source Code Pro"; f= ont-size: 13.333333015441895px;">>the
&= gt;> > > MTA,
>> > > = > the MDA or both?
>> > > &= gt; 
>> > > > If both = are supposed to do it, can the A-R header be extended
>in such
>> > >= a
>> > > > way, that only = the MTA does the sampling, and
>> &g= t; > > carries the information to the MDA?
>> > > > 
>&= gt; > > > Regards
>> > &= gt; >  =D0=94=D0=B8=D0=BB=D1=8F=D0=BD
>> > > > 
>>= ; > > > On Tue, 2019-07-30 at 13:56 +0000, Scott Kitterman wrote:<= /font>
<= font color=3D"#737373" style=3D"font-family: "Source Code Pro"; f= ont-size: 13.333333015441895px;">>> > > > > The published= policy (that's why I suggest dmarc.policy). 
>I'm not
>> > > &g= t; sure if disposition belongs in A-R.  If it does, it'd be a>local
>>= ; > > policy
>> > > >= override, probably policy.dmarc as described now in RFC 8616.
>> > > > > Scott K
>> > > > > 
>> > > > > On July 30, 2019 1:34:46 PM UTC, "= =D0=94=D0=B8=D0=BB=D1=8F=D0=BD =D0=9F=D0=B0=D0=BB=D0=B0=D1=83=D0=B7=D0=BE= =D0=B2"
>> > > > <dilyan.palauzov@aegee.org> wrote:
>> > > > > > Hello Scott,
>> > > > > > 
>> > > > > > do you want to include = in the A-R header the published
>policy= , as
>> > > > > > obt= ained from DNS (my first interpretation of your
>> > > > > > proposal), or the disposition of th= e message after applying
>> > >= ; > > > DKIM/SPF/DMARC validation, pct sampling, and the ominous
>> > > > > > reject=E2= =86=92quarantine sampling conversions?
>= ;> > > > > > 
>&= gt; > > > > > With disposition I mean what is called at
>> > > > > > https://tools.ietf.or= g/html/rfc6591#section-3.2.2
>> = > Delivery-Result.
>> > > &= gt; > > For the disposition on p=3Dreject only the MTA can make the
>> > decision
>> > > > > > based on pct to reject, so i= t makes sense if the
>> > > &g= t; > > result of disposition is included in the A-R header by the
>MTA
>= > > and
>> > > > >= > consumed by the MDA.  In turn, including pct and
>> > > > > > published DMARC policy = in the A-R header, so that the MDA
>can= do
>> > > > the
>> > > > > > sampling, does not= make sense.
>> > > > > = > 
>> > > > > &g= t; If you want to call the new parameter =E2=80=9Cpolicy=E2=80=9D, then it<= /font>
<= font color=3D"#737373" style=3D"font-family: "Source Code Pro"; f= ont-size: 13.333333015441895px;">>shall be
>> > > > > > articulated that it means dispositio= n, and not
>> > > > > &g= t; published policy.
>> > > &g= t; > > 
>> > > >= > > I am in favour of the proposal.
>> > > > > > 
&= gt;> > > > > > It allows for forwarded emails/aliases to = indicate in the
>A-R
>> > > > header,
>> > > > > > that sampling was already performed = by the
>> > > > > > a= liasing server, and the final server that accepts the
>email can
>> > &g= t; > skip
>> > > > > = > performing the sampling again.  Performing the
>> > > > > > sampling again has the dis= advantage, that the pct=3D
>parameter i= s
>> > > > > > misint= erpreted, as the parameter is supposed to be
>> > > > > > applied only once.
>> > > > > > 
>> > > > > > On the other side, skip= ping of the second sampling by
>whateve= r
>> > > > server>> > > > > > is pure theory, a= nd has no practical impact.
>> > = > > > > 
>> > &g= t; > > > Greetings
>> > = > > > >  =D0=94=D0=B8=D0=BB=D1=8F=D0=BD
>> > > > > > 
>> > > > > > On Tue, 2019-07-30 at 00:54 = -0400, Scott Kitterman wrote:
>> >= ; > > > > > On Monday, July 29, 2019 3:37:55 PM EDT Scott Ki= tterman
>wrote:
>> > > > > > > > I'd like to add the o= ption to record DMARC results in
>an A-= R
>> > > > header>> > > > > > field
>> > > > > > > > for cons= umption by a downstream processor.  I think it
>would
>> > > be<= /font>
<= font color=3D"#737373" style=3D"font-family: "Source Code Pro"; f= ont-size: 13.333333015441895px;">>> > > > > > somethin= g
>> > > > > > > &= gt; like this:
>> > > > >= ; > > > 
>> > > = > > > > > Authentication-Results: mail-router.example.net;
>dmarc=3Dpass
>> > > > > > > > header.from=3Dexample.co= m policy.dmarc=3Dnone
>> > > &= gt; > > > > 
>> >= ; > > > > > > That would take adding an entry in the Emai= l
>Authentication
>> > > > Methods
>> > > > > > > > for:
>> > > > > > > > 
>> > > > > > > > method: dma= rc
>> > > > > > > = > ptype: policy
>> > > >= > > > > value: dmarc
>>= > > > > > > > 
= >> > > > > > > > Does that make sense as a way t= o do it?  Does anyone
>have=
>> > > > > > alternative
>> > > > > > > > = suggestions?
>> > > > > = > > 
>> > > > &g= t; > > I think comments should be free-form.  If we want data
>that can
>> >= > > > > machine 
>>= ; > > > > > > parsed, we should specify it.
>> > > > > > > 
>> > > > > > > I think the a= bove works in ABNF terms.  It's:
>= > > > > > > > 
&= gt;> > > > > > > Authentication-Results:" authserv-id;= method=3Dresult
>> > > > &= gt; > ptype.property=3Dvalue 
>= > > > > > > > ptype.property=3Dvalue
>> > > > > > > 
>> > > > > > > According to = the ABNF, there can be more than one
>p= ropspec 
>> > > > >= > > (ptype.property=3Dvalue) per methodspec in resinfo, so I<= br style=3D"caret-color: rgb(46, 52, 54); color: rgb(46, 52, 54); font-fami= ly: "Source Code Pro"; font-size: 13.333333015441895px;">>think
>&g= t; > > it's
>> > > > = > > legal.  It 
>> &= gt; > > > > > would just need the new registry values for dm= arc.
>> > > > > > >= ; 
>> > > > > > = > Scott K
>> > > > > = > > 
>> > > > &g= t; > > 
>> > > >= > > > _______________________________________________
>> 




I know that Gmail and others put = that information in the comments, but that probably shouldn't be for someth= ing explicitly part of the spec like this.

Anyways= , +1 to keeping p=3Dquarantine as a concept, but willing to go along w= ith the consensus on naming.

Brandon 
_______________________________________________
dmarc mailing list

--=-jz9tM/IdWIEWr2u/ytDj-- From nobody Tue Dec 8 04:32: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 56E873A0C92 for ; Tue, 8 Dec 2020 04:32:19 -0800 (PST) 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 uZFF8hlDcDAp for ; Tue, 8 Dec 2020 04:32:14 -0800 (PST) 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 804023A0C96 for ; Tue, 8 Dec 2020 04:32:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1607430731; bh=4Sp7S0Sr7QZ9X/USQUnSVy6nF4TQxTzm7I8WkYHFn1E=; l=1444; h=To:References:From:Date:In-Reply-To; b=DFzk2RX5H6SU4gE98b+53EO6C4RDqRhqprP9d2tpXg3iaUjKMOyl/iqGG0vuAqcov EduPPLfsRysgc69vxgUhaQzLKncwkSnXyAgz+f8khGfu+xAGggAhf2EeAHvWkWL3Fq dxq6p4O5SIP1FGm8aabojtICp3KPGYTnHGbHee+kF/7ax+2kTPyJI507SIcVi Authentication-Results: tana.it; auth=pass (details omitted) Original-From: Alessandro Vesely 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 00000000005DC0DC.000000005FCF724B.0000132C; Tue, 08 Dec 2020 13:32:11 +0100 To: dmarc@ietf.org References: <0408ae98-e1c1-71fe-fdd4-8bc7a7c151d3@tana.it> From: Alessandro Vesely Message-ID: <62b7d80e-2c39-4d02-0b5a-bd6ede7d51dc@tana.it> Date: Tue, 8 Dec 2020 13:32:11 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Ticket #28 - Failure report mail loops X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2020 12:32:19 -0000 On Mon 07/Dec/2020 20:51:12 +0100 John Levine wrote: > In article , > Alessandro Vesely wrote: >>> 4. Some explicit loop prevention specification may be added. For example: >>>> 4.1. send reports from a subdomain having a DMARC record without ruf=, or >>>> 4.2. never send failure reports about failed reports. >>> >>> The latter, which is consistent with SMTP never generating a bounce about a >>> bounce. >> >>However, SMTP has an operational definition of bounce, MAIL FROM:<>. Should we >>take the same stance? That is, send failure reports with an empty bounce >>address and never send failure reports to bounces or failure reports? > > We're talking about DMARC failures, not SMTP delivery failures. I > don't see what the latter has to do with the former. When dmarc authentication method fails on a message, an MTA may decide to send a failure report. If the message is itself a failure report, however, no failure report should be sent. The question is, how does the MTA determine whether the message is a failure report, without resorting to lengthy content analysis? One possibility is to never send failure reports when the bounce address is empty, and mandate that failure reports be sent with an empty bounce address. That way, also regular SMTP bounces won't be reported if dmarc authentication fails. Overly simplistic? Ale -- From nobody Tue Dec 8 04:52: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 85C1F3A0D2F for ; Tue, 8 Dec 2020 04:52:02 -0800 (PST) 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 sypjod1A9STG for ; Tue, 8 Dec 2020 04:52:01 -0800 (PST) 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 0C3F03A0D25 for ; Tue, 8 Dec 2020 04:52:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1607431918; bh=Apet6lAi0L03ycYIRINCGDHgv45UF3QI1y/fW02RidE=; l=895; h=To:References:From:Date:In-Reply-To; b=DP3y/GCoiYWvbO06e+PUN/H5HVwJMoHGa6QdWCOn+RU7Q6cPGOXqgj21i3F8D/iGc NvXksAM34JtMr2FVuXAi8wwhyp808ckdgm8jfZGfvbjfkZZs784pLWLGW2Npkq5G5H HOb4nUqDrc+n+TctxEGs8TXccVGLI+JKMrIsZS2Z0QV6BRRM0ZI9O/GPesFyO Authentication-Results: tana.it; auth=pass (details omitted) Original-From: Alessandro Vesely 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 00000000005DC0CD.000000005FCF76EE.000015EC; Tue, 08 Dec 2020 13:51:58 +0100 To: John Levine , dmarc@ietf.org References: <20201207191959.6D772292166A@ary.qy> From: Alessandro Vesely Message-ID: Date: Tue, 8 Dec 2020 13:51:58 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: <20201207191959.6D772292166A@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] ARC vs reject X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 08 Dec 2020 12:52:10 -0000 On Mon 07/Dec/2020 20:19:59 +0100 John Levine wrote: > In article you write: >> Compared with the use of "l=" tag (Section 8.2 of [RFC6376]), the >> fact that footers are written in plain text ... > > They are? Some are, some are added as MIME parts. The Content-Type: of the added MIME part, in that case. > We really need to keep in mind that there is a lot of list management > software with a vast array of configuration options. The idea of the draft is that being reversible is a MLM configuration option. The simplest case is that of lists that don't modify messages at all. Nothing to revert in this case. We can extend that case so as to include the addition of a simple footer and a subject tag. That way, at least, we can discuss DMARC standardization on a DMARC-compliant mailing list. Best Ale -- From nobody Tue Dec 8 06:57: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 694F73A0FB1 for ; Tue, 8 Dec 2020 06:57:19 -0800 (PST) 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 WbAxCYP1hbmH for ; Tue, 8 Dec 2020 06:57:16 -0800 (PST) Received: from mail-qt1-x82e.google.com (mail-qt1-x82e.google.com [IPv6:2607:f8b0:4864:20::82e]) (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 B699C3A0FD3 for ; Tue, 8 Dec 2020 06:57:13 -0800 (PST) Received: by mail-qt1-x82e.google.com with SMTP id p12so12070414qtp.7 for ; Tue, 08 Dec 2020 06:57:13 -0800 (PST) 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=8mXyH9BRQ/A2apqum3CtqUzxtTn5r+RptI39iyhU64I=; b=smHBZ0xylUSjse3H5Jl2Luzl7hGXBhZaLBQUlcdgGV3FbX3lkiCooNXhrF7Fl7+q3J Zq3Oymx4yuTReqikTbijbEmgiohwuk+SHZrAnZOFibW+v0H6iRNwEy6ZSA5QqRB0ZHeI 8bn5BHuXrmdZz/jtblQ4GgzencNvIhTtRdyRWfjYM/GX1SFCoqCO78tKO2goUUEkepTb t0Hu3ezBVgQMYRuW3z4W32fHStC8DPxr4RqjCaWwSi4gXPwVfVS3NqvGpEoxhMX1vDW9 kPjJmvGBoYQ7+30ePIhUtEpbwdpq76svP/kC2DWXEhNSUwCjpsgiA4iavHVEFLJVVVbP t6ng== 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=8mXyH9BRQ/A2apqum3CtqUzxtTn5r+RptI39iyhU64I=; b=BPfAoZzEDmLbb8pnY5P9Ahj7Pd8ZlQrSXw//QfXZ0oXKoG7i8pl5yd2WTxKxQmc1LA sS4ZEudu1K/+TdoO5XWAgPpnoqiJckhzWXKRTpKTPir5fBR+8t0FSGSRnbchPC9ZWRLL LdMXYlDjIHDJ8IjJBjORGm+cOQBMS/2IPA0SjL4BeoP3GIAeB0qSpMZCY1M43xokDAmH jDqOuZk6rA4wvZ5zZGDdbsIFTpc+NLP4bRscpNdVFPr8OA9bcbSfy3tUN/GLjKuMWAhA xOH3/BG5V4zFRBfSLnNqEH4qY3wMf9VkgH328tT9pOBg8h2XjYuJJLLLsYfPLR9OC1WL zvLw== X-Gm-Message-State: AOAM5300dP8nqOKvMw0yY+vdpgH55oXYPvbZpEfi0eoHIFDNs/ADeFdk 9S+TyUp5CXzlnDgYxOHdi9qhFz1vqUCOh6iXyScylTcA X-Google-Smtp-Source: ABdhPJy0zCqm6h6naiDhIsa0WdODoFxiw+Njs/48YvANIMMOCiOnCfk5Whndehna0jQ2xA7q/hKrJOwVcqB7/uu9Nmc= X-Received: by 2002:ac8:6bc2:: with SMTP id b2mr14604115qtt.286.1607439432691; Tue, 08 Dec 2020 06:57:12 -0800 (PST) MIME-Version: 1.0 References: <20201207214133.2D5142922931@ary.qy> In-Reply-To: <20201207214133.2D5142922931@ary.qy> From: Dotzero Date: Tue, 8 Dec 2020 09:57:01 -0500 Message-ID: To: John Levine Cc: IETF DMARC WG Content-Type: multipart/alternative; boundary="0000000000006235cd05b5f52839" Archived-At: Subject: Re: [dmarc-ietf] Ticket #42 - Expand DMARC reporting URI functionality X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 08 Dec 2020 14:57:26 -0000 --0000000000006235cd05b5f52839 Content-Type: text/plain; charset="UTF-8" On Mon, Dec 7, 2020 at 4:41 PM John Levine wrote: > >I don't understand the security or GDPR references. > > Well this is amusing. I wondered if anyone had ever implemented some > version of the http reporting in early DMARC drafts, so I set up a new > domain > with a server that will accept POST or PUT requests and added its URI to my > DMARC records. > What is tht "mantra"? Running code and rough consensus? Has anyone implemented such reporting? > > I didn't get any of those (the POSTs below are not to the right URI) > but it's impressive how fast Russian bots started to probe it, within > hours. > I thought it's about interoperability. Simply having a webserver running doesn't come close to interoperability, and certainly not at scale. > > This is not a reason to avoid https reporting. Every web site gets > probed like this and so long as your web server rejects unknown URIs, > they're harmless. After all, my e-mail reporting addresses get a > certain amount of spam, too. > > R's, > John > My question was not intended to imply that HTTPS reporting should be avoided. My point was that there has been basically no security discussion or scrutiny of such an implementation. This document is now proposed Standards Track, not Informational or Experimental. As such, proposed changes or additions should be given. Your surprise at what happened so quickly after your "implementation" proves my point that there has been little if any thought of security considerations for this proposed change. My comment about GDPR was simply meant to indicate that the world has changed quite a bit since DMARC was made public in 2011. So too have security considerations evolved. I have no objection in principle to HTTPS reporting, only that such an addition be given the same consideration and scrutiny that DMARC itself is being held to. Michael Hammer --0000000000006235cd05b5f52839 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Dec 7, 2020 at 4:41 PM John L= evine <johnl@taugh.com> wrote:=
>I don't= understand the security or GDPR references.

Well this is amusing. I wondered if anyone had ever implemented some
version of the http reporting in early DMARC drafts, so I set up a new doma= in
with a server that will accept POST or PUT requests and added its URI to my=
DMARC records.

What is tht "mantra= "? Running code and rough consensus? Has anyone implemented such repor= ting?

I didn't get any of those (the POSTs below are not to the right URI) but it's impressive how fast Russian bots started to probe it, within hours.

I thought it's about interop= erability. Simply having a webserver running doesn't come close to inte= roperability, and certainly not at scale.
=C2=A0

This is not a reason to avoid https reporting. Every web site gets
probed like this and so long as your web server rejects unknown URIs,
they're harmless. After all, my e-mail reporting addresses get a
certain amount of spam, too.

R's,
John

My question was not intended to imply t= hat HTTPS reporting should be avoided. My point was that there has been bas= ically no security discussion or scrutiny of such an implementation. This d= ocument is now proposed Standards Track, not Informational or Experimental.= As such, proposed changes or additions should be given. Your surprise at w= hat happened so quickly after your "implementation" proves my poi= nt that there has been little if any thought of security considerations for= this proposed change. My comment about GDPR was simply meant to indicate t= hat the world has changed quite a bit since DMARC was made public in 2011. = So too have security considerations evolved. I have no objection in princip= le to HTTPS reporting, only that such an addition be given the same conside= ration and scrutiny that DMARC itself is being held to.

Michael Hammer
<= /div> --0000000000006235cd05b5f52839-- From nobody Tue Dec 8 07:54: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 926903A0FEC for ; Tue, 8 Dec 2020 07:54:33 -0800 (PST) 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 (2048-bit key) header.d=iecc.com header.b=bldSSCnp; dkim=pass (2048-bit key) header.d=taugh.com header.b=FwJjQF9u Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WvVQoQ0MozNG for ; Tue, 8 Dec 2020 07:54:31 -0800 (PST) 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 5E6983A0FED for ; Tue, 8 Dec 2020 07:54:30 -0800 (PST) Received: (qmail 71246 invoked from network); 8 Dec 2020 15:54:29 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type; s=1164a.5fcfa1b5.k2012; i=johnl-iecc.com@submit.iecc.com; bh=C/Eq6qpg7ZZwF2JrYN90z11d6wW2L3qa7QzL09GQa4I=; b=bldSSCnpriryIr7w6gmNfOoZI2vFZ/Pkerg7y8GW46eAOfOK6lXeqkwFHaNXJKrGWhgaSvfyrIkd4HjM7U7Ycvfkw8vcoDWMzWLd4pk40G9Hc0CHjhbRov3S3CbMPKPxggw0IkU25Sern9uW2/8ROuRXac3zDYFbLA2nMgE6v8oaal3UqN5rc9esLJNyPfbvkGlQoS0KYrhIq9IBsbiODd8Vc2GUQDTyz+Uufz4okLOYWDrQxpX+bt0Wgh8PQ5B7iTE+hgrUbewX8KHqOkrjDKwjlSIENr/kIQLRMea8utvPFQN601ExO+qYO4Surg3vxzoOhy/DY3mAVwbhRXXa+Q== 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=1164a.5fcfa1b5.k2012; olt=johnl-iecc.com@submit.iecc.com; bh=C/Eq6qpg7ZZwF2JrYN90z11d6wW2L3qa7QzL09GQa4I=; b=FwJjQF9uMSS781vbv3ALVYwuhDJP1+PQ/e4co2sBLsAlPnSaKt+FtZ636FzhCyOtZDf/G9bl/Svo8/HFgmjhQ5rPo94Ggt8+4Yia32OY6YKID0MiQtGjKc8oEJPzorQPY07HuX9Ib6m4TltSN9eGv1L9HZpBLdUh/0BRuXHsFKEyNvHyfpVvz8+giSJ3szGMuL3u7w5LIEunRLtLJ27IBapXjiDarKjcgXR+mkueT0/eRFXOEbzLJssw6KWoIebfvW7lM3BQI+Q1XhF7s1dK638ryJRJuTMDSi1e0UxqrxS8q1k+BJu24EV5wc+VPQmySJg7iMk4S4irxqibr1CpMg== 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; 08 Dec 2020 15:54:29 -0000 Date: 8 Dec 2020 10:54:28 -0500 Message-ID: From: "John R Levine" To: "Dotzero" Cc: "IETF DMARC WG" In-Reply-To: References: <20201207214133.2D5142922931@ary.qy> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [dmarc-ietf] Ticket #42 - Expand DMARC reporting URI functionality X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 08 Dec 2020 15:54:34 -0000 >> I didn't get any of those (the POSTs below are not to the right URI) >> but it's impressive how fast Russian bots started to probe it, within >> hours. > > I thought it's about interoperability. Simply having a webserver running > doesn't come close to interoperability, and certainly not at scale. I guess I wasn't clear enough. I know there's no http reporting in DMARC, but there was in an early version of the spec. I was wondering if anyone had implemented that. Apparently not. > My question was not intended to imply that HTTPS reporting should be > avoided. My point was that there has been basically no security discussion > or scrutiny of such an implementation. That's fine but as I said I think it is clear that the security of https reporting is better than of mail reporting. 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 Dec 8 09:18: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 AF5683A1051 for ; Tue, 8 Dec 2020 09:18:28 -0800 (PST) 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=LUAoZ8Jv; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=0Gd4dUZp Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eUqRhkMT80VA for ; Tue, 8 Dec 2020 09:18:26 -0800 (PST) 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 B6E9E3A104B for ; Tue, 8 Dec 2020 09:18:25 -0800 (PST) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha256; c=simple/relaxed; l=7537; t=1607447897; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=unQ/cVDy9FYBRtGqvpawX3Y6uVLn RxhTb9vqDMKWi5c=; b=LUAoZ8Jvz1zbq3kKNm0qH1N2Yxixl4WiL1g8U+LKGd/r hzzf8xPJuhT0aDqvwltx8+4OBLCBBrL6PqubP+aWKOS0IK344SOKWGqtC+AxB0i9 gp05Z6VIbBwoJcNiNY/D4MKdVT1isr7OVEI41mdgIwuanqmBRlUp4Akdx0BKdyc= Received: by mail.winserver.com (Wildcat! SMTP Router v8.0.454.10) for dmarc@ietf.org; Tue, 08 Dec 2020 12:18:17 -0500 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 887981359.1.4088; Tue, 08 Dec 2020 12:18:15 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=7537; t=1607447557; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=unQ/cVD y9FYBRtGqvpawX3Y6uVLnRxhTb9vqDMKWi5c=; b=0Gd4dUZp/if0o2dYV7FcHN8 Q9BIKG/3aQ8p9+dYpLuYgQ2CHxnID4Zbew9KCUCiZ/3YdmfDBuEhQJbSGueroNk8 ZwkUlazQwwr9HRIHZKzc/EXI8YuSNpytgVy6nEF7TvmRSc+i9P0fdo0plKxM7YOD u3Pk2ytZeBBcQVSzsyV4= Received: by beta.winserver.com (Wildcat! SMTP Router v8.0.454.10) for dmarc@ietf.org; Tue, 08 Dec 2020 12:12:37 -0500 Received: from [192.168.1.68] ([75.26.216.248]) by beta.winserver.com (Wildcat! SMTP v8.0.454.10) with ESMTP id 754862236.1.12368; Tue, 08 Dec 2020 12:12:37 -0500 Message-ID: <5FCFB555.2050800@isdg.net> Date: Tue, 08 Dec 2020 12:18:13 -0500 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: =?UTF-8?B?0JTQuNC70Y/QvSDQn9Cw0LvQsNGD0LfQvtCy?= , Brandon Long , "Murray S. Kucherawy" CC: IETF DMARC WG , Dotzero , Benny Lyne Amorsen References: <20201202021651.E8EE128C576A@ary.qy> <327860af-2fa7-63ee-4b89-6e7e383f3d53@crash.com> <2804da89-84d1-f601-9425-0b0d9baf6ae1@gmail.com> <1f6cae74-4eed-47f5-7249-e526bf1f5845@crash.com> <87y2ig9t9i.fsf@orion.amorsen.dk> <1ddcc797fb34a9d45b9467a7a86c49751e013561.camel@aegee.org> In-Reply-To: <1ddcc797fb34a9d45b9467a7a86c49751e013561.camel@aegee.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] Ticket #39 - remove p=quarantine X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 08 Dec 2020 17:18:29 -0000 On 12/8/2020 6:24 AM, Дилян Палаузов wrote:> Hello, > > I do no see the point of having all the discussions here, as nobody is > capable to read and understarstand all written emails in their whole > quantity. I personally do not follow the discussions anymore, apart > from reading the subjects… +1 Major Plus One. Its all deja vu. Optional reading. I'll use this opportunity to express my key summary concerns as a long time DKIM and SPF implementation and commercial DKIM/SPF product vendor. FWIW..... We have a Developer vs Administrative protocol design issue once again. Too many philosophical "Administrative" subjective opinions trying to burn their idea into how IETF protocols is written and how implementations should behave operationally from an admin standpoint. The DKIM POLICY model is a simple DNS lookup protocol, like SPF. It hasn't change since day one. DMARC is just the current rendition of the same thing since SSP - nearly 15 years - plus Reporting which was rejected for SSP and ADSP. Unlike SPF, what DKIM POLICY lacked 3rd party authorization protocol support. But we had discussed the idea of using SPF softfails as a way to link together with a valid DKIM result. I recall Microsoft was exploring this methods as one the early explorers of ADSP. I liked the concept and explored it myself by looking at a possible "fuzzy" logic of the results, for example: SPF PASS + DKIM PASS => Result PASS (confidence? 100%) SPF SOFTWARE + DKIM PASS => Result PASS (confidence? 80%) SPF NEUTRAL + DKIM PASS => Result PASS (confidence? 50%) SPF FAIL + DKIM PASS => Result PASS (confidence? 0%, SPF fail preempts DKIM?) But when it came to the new filtering protocols we were development, I was more interested in 100% or 0% deterministic protocol results. Anything in between is "fuzzy" and imo, can't make hard filtering unless we are now learning from the BIAS from Deep AI methods. For many, Pareto's 80% may be good enough for a filtering decision. It is well established, DKIM POLICY works for 1st party signatures. We know this since day one. The proof of concept was long set in stone and never to be killed. We documented it in the early initial DKIM WG work productions - Thread Analysis and the Functional specification: 2006 RFC4686.txt Analysis of Threats Motivating DKIM 2006 RFC5016.txt Requirements for a DKIM Signing Practices Protocol DKIM Policy is a powerful concept and in the words of one of the key cogs - "Its scary!" Yes, for direct 1 to 1 private mail, you have a very powerful way to protect against domain spoofing in the same way SPF protects against unauthorized transports from unknown machines. SPF has its "in-direct" issue with routing of transports which I called a "Node Transition" point. DKIM was initially marketed as a solution to the node transition problem. The stage was set. SSP with its 3rd party options, defined the ideas that a domain, like SPF, can describe which domain(s) can "notarize" the email. But we did not have a way to define the authorized 3rd party domain. The simple idea was to use tag= list, like a Access control list, for example acl=ietf.org, gmail.com which it reduced the need for another DNS lookup. The acl= tag works for a small well organization network. But it does not scale. ATPS was written to some some like of scalable using a zone record per 3rd party authorized domain. ATPS starts with a tag: atps=1 and if enabled, receiver will check for the signer domain authorization ATPS record. Does it work for all, no. But it works for many and its been in production since 2012. The DMARC or DKIM Policy protocol payoff does not come from positive passed results but rather with failed results because the protocol raises the bar by authorizing the receiver to reject or discard or quarantine a.k.a filter a message for the sake of the end-user. Side note: There are four states for mail transport: - Reject (SMTP does not accept it). - Accept (user sees it in inbox, may be filtered with other things) - Accept & Discard (lost to the user) - Accept & quarantine (move to spam box, outside the main inbox stream) The p= policy not only should keep quarantine, it should add p=discard Unfortunately, a key moment came, in RFC5016, section 5. item 10, when the beginning of this long 14+ year "fight" with Mailing list administrators started, imo. This was when all the heart aches became to occur, the major disagreements between Policy Advocates and Trust Advocates. Read it carefully. Its about local policy (duh), but this last minute item provision altered the future of DKIM POLICY. Every since then, we had his long debate of DKIM-POLICY Model vs Mailing List Systems. It basically lead to this protocol conclusion: DKIM POLICY does not work for Mailing List unless the Mailing List Server vendors supports and honors the DKIM POLICY model - period. If it does not, it will have trouble integrating into a new DKIM with optional restrictive policies world. I know of only one commercial List Software vendor, Wildcat! List Server, that supports the DKIM Policy for Restrictive Policies. It does not have the issue with in-direct mail submissions. New subscribers from restrictive domains are not allowed to subscribe. If already a member of the list, list members from restrictive domains can not longer post but they can continue to receive a distribution (iow, a read only member). For a long time, we had folks that believed "list servers" were so old in their ways they are not obligated to change or adapt to the DKIM policy model. I understand that. Wildcat! List Server is one of the older systems around. Yet, the same folks advocated making non-standard provision changes to intentionally ignore restrictive DKIM Policies, continue distributing changed and unprotected original domain mail by destroying the trust of the mail system by altering the "READ-ONLY" field 5322.From. Anyway, thanks for pointing this out. I second your concern. Its not pretty what is going on. I hope key folks with the IETF are made aware that this is not normal. I believe we need to recognize the need for augmented DKIM Policy Tag extensions that could do the various Product Support Features some people are looking for. I don't like ARC, too much overhead and its not addressing the key lack of authorized 3rd party domain concerns, but if GOOGLE wants to push this idea, than the ARC Protocol should extend DMARC with "arc=" related tags. I am on the fence of whether DMARCbis should mention ARC. I don't think so if its an experimental. I don't think we did this for a proposed standard to be referencing experimental work. But in any case, maybe the tag "arc=1: means that it promote SPF or DKIM fails? In theory when combining ARC to SPF and DKIM, we now have: SPF(4)+DKIM(2)+ARC(2) == Final Result(16) There are 16 combinations for SPF, DKIM and ARC states. Some will fold, some will not make sense. I won't argue the WG decision to add ARC to DMARC in some matter. But don't ram it down our throats. Allow domains to explore with an "ARC=1" tag in their DMARC record, then at some point in the future, as we learn more, it can be explored. But imo, we should not speak of a DKIM Policy Protocol as if ARC is a natural part of it. Thanks for reading. -- Hector Santos, https://secure.santronics.com https://twitter.com/hectorsantos From nobody Tue Dec 8 09:41: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 118D63A1065 for ; Tue, 8 Dec 2020 09:41:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.651 X-Spam-Level: X-Spam-Status: No, score=-1.651 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mtcc-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D7LIZ8gsyD9r for ; Tue, 8 Dec 2020 09:41:52 -0800 (PST) Received: from mail-pl1-x632.google.com (mail-pl1-x632.google.com [IPv6:2607:f8b0:4864:20::632]) (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 D9DC53A105E for ; Tue, 8 Dec 2020 09:41:52 -0800 (PST) Received: by mail-pl1-x632.google.com with SMTP id p6so7342318plo.6 for ; Tue, 08 Dec 2020 09:41:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mtcc-com.20150623.gappssmtp.com; s=20150623; h=to:from:subject:message-id:date:user-agent:mime-version :content-transfer-encoding:content-language; bh=Y1LUOLnXgv/rHABatsm60ASea4US+GzTx6hvFEZyXTI=; b=O16MS0pd5IATYPbmr5WaNBgjCL8hEwt8uSqy8Njw2MArCoo6/rhIrpuFVRbadWao0z gQ0pIme8myn3kj6GP8D0YvBV0kBiMhJCRSvBHRJp3fgD7mpI99NPTBcNoqRn9Q0Ru8Hl XeJRMdSBPfyBmWBpJhLMytxJi6ZPX1t5tHWu2q6mrJbYDwhNoy+yIaWIhWBjZgVBwFAD TAUsB/UOxxrw2svBAPCajFqWc1NOWqoF0wothBqm0180b7gkxDEdb14Hwandy57USbmv doOUDyMEbe12OQh5etsWvl9pSoQ00pYOlqvl6ewAm+138I9/TwArlp4Jw/ymuNrt3IbQ bfmA== 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-transfer-encoding:content-language; bh=Y1LUOLnXgv/rHABatsm60ASea4US+GzTx6hvFEZyXTI=; b=t1y7LPrc8LhzpJiHQ+NRaWARKY3jMyxBBRy2xzKKTq/za7Z/qAIIITh0gaByDFjSuf YNJMaEiD12LzVt38d/6GKbO66O/bYgPYDeFF9eve/iPuyAX6wDBwAssapfa9/6qE8lVG tZrJ3YUhH3fsqS9ZrZVj++tuiI2qdOS8IPixfw0CA6SdwwTKULqQREFoPl2sNhEAVBUy hpbbep4f8ZY1832x5hZlm2+VvTh2ZZ9dsE+vbl0omE4ne6yJOh6OESSwWPi89TwbSPu6 ORUqQNMUsMyJUrMO8L5SEui3I5CqUHJ1T9TnmkwEZOSo/KAkuF681sVdlyRUIZ7628pJ NMJA== X-Gm-Message-State: AOAM531Xt/g46/ay6yPYBgD0qv3DV1lj4XsdQB+BNqf86Lskb88OT+MT KxNNUJqJusI3B8mFerOiZde8J2b9KddT6w== X-Google-Smtp-Source: ABdhPJwpCsv7a+///9dgjR7DznkUTMVIWKdy+4tn73vSYSuLBPLwmVv9aNeiyNJb1B99TwftptheRw== X-Received: by 2002:a17:902:b7c3:b029:da:76bc:2aa9 with SMTP id v3-20020a170902b7c3b02900da76bc2aa9mr21947935plz.21.1607449310057; Tue, 08 Dec 2020 09:41:50 -0800 (PST) Received: from mike-mac.lan (107-182-41-154.volcanocom.com. [107.182.41.154]) by smtp.gmail.com with ESMTPSA id r67sm18850772pfc.82.2020.12.08.09.41.49 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 08 Dec 2020 09:41:49 -0800 (PST) To: "dmarc@ietf.org" From: Michael Thomas Message-ID: <9e1ce2a0-cb64-067f-dc74-aa384cf34ebd@mtcc.com> Date: Tue, 8 Dec 2020 09:41:48 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: [dmarc-ietf] p=quarantine X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 08 Dec 2020 17:41:54 -0000 If you take the literal meaning of quarantine, that means that every piece of email from this and every other mailing list would end up in a quarantine folder, or some such. I'm fairly certain that is not what people want, and I'm doubtful that many receivers implement that. The question to my mind is whether there actually exists a state between "we don't know" and "trash it because it's not from us". "Quarantine" seems to mean "be more suspicious of this", but I'm not sure if that is of any help to filters. Ultimately it's whether filters find these policies useful is what actually matters. Don't we have enough data lying around these days to inform us? If filters are ignoring it, then it's rather pointless. This discussion (and many others) should be data driven, IMO. Mike From nobody Tue Dec 8 10:25:04 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 B4E5B3A1083; Tue, 8 Dec 2020 10:25:01 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: dmarc-chairs@ietf.org, superuser@gmail.com, alexey.melnikov@isode.com, dmarc@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.23.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <160745190172.15620.17081247178872475062@ietfa.amsl.com> Date: Tue, 08 Dec 2020 10:25:01 -0800 Archived-At: Subject: [dmarc-ietf] dmarc - New Meeting Session Request for IETF 110 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2020 18:25:02 -0000 A new meeting session request has just been submitted by Alexey Melnikov, a Chair of the dmarc working group. --------------------------------------------------------- Working Group Name: Domain-based Message Authentication, Reporting & Conformance Area Name: Applications and Real-Time Area Session Requester: Alexey Melnikov Number of Sessions: 1 Length of Session(s): 1 Hour Number of Attendees: 76 Conflicts to Avoid: Chair Conflict: dnsop dprive cfrg kitten emailcore Technology Overlap: saag uta extra jmap cbor People who must be present: Alexey Melnikov Murray Kucherawy Tim Wicinski Seth Blank Resources Requested: Special Requests: --------------------------------------------------------- From nobody Tue Dec 8 10:50: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 C81473A10BD for ; Tue, 8 Dec 2020 10:50:31 -0800 (PST) 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 Kbi95J6rHJLD for ; Tue, 8 Dec 2020 10:50:30 -0800 (PST) Received: from mail-qv1-xf32.google.com (mail-qv1-xf32.google.com [IPv6:2607:f8b0:4864:20::f32]) (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 6E53E3A10BA for ; Tue, 8 Dec 2020 10:50:30 -0800 (PST) Received: by mail-qv1-xf32.google.com with SMTP id s6so979775qvn.6 for ; Tue, 08 Dec 2020 10:50:30 -0800 (PST) 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=3bEaTs9mAM9vEBW7tmYo4WzSGNVOILGWtW41GFBVIN4=; b=iSw/oAPhgNZqUYDAiYQLHEaRiMW/Z/xlD9stgksPLnxsw1o1C7QO5zQLGIiNIGNuet Gy2NPLqzfvuztyd8RkLAFhMzFgG2VlBdt9K/zaJcUa5m0BOFma7dHVto+d8VVfKmEz8z zHEF6tQ8zNz01MgwioLa/gpmmuQou5sndkE49DTKok+8LKZLzqjBLwpXuGj8GD+EtnKp 7HjCiNhWb8PyCFWJibnHCSLv4tSyd4Leznw0iV+Rd8ez2SfQapIUtyRughzsYoH8mOD+ eHeoqO2El0mwdRdwSUqVuwkrhr35lCEt9NZD49rnb4tMbncORCHtQ/GnCFIg6JDBHvE5 c45g== 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=3bEaTs9mAM9vEBW7tmYo4WzSGNVOILGWtW41GFBVIN4=; b=IEYbvdVIbAawNhU/NZQdb1YOiplJHDzJmPXUJ33b93pvSs02lFTqNKEolLgCmoKZk2 rBgntIvuVi+i28bo3M/RBzadhh3jTm/Mkk7CVXGPDJtRCTBkhX4w+qaGeqz0IkSAlTOD RPcg/fFwFIV4pmDsbhV4Q1PQ786ZYN/WBNs52G1HyFGPrhn6t5jstT4CcEeuHkUxm/gq 5mLCPOiuMi2eOr0lKmXNj+ixnFuAn5bd/jB6CgMBOfq1qdMQkxE/cV6LGhEGv8JoadW4 oaiqKZXI3nPf0ZrA0UM1b7TbgVgAarc7fduZe+vUFZVJIgXHrQPPX6USO6sKDkpYaFmu +BMg== X-Gm-Message-State: AOAM532Jxdh2j3t5PFB0nfet7ahdmj2vZOqs1eXzFn3X2V+dOMahlV0e M6meA3lZlPkvXtN4K3QFaBeMV0jbwnUqDFGp8e2xaoH7 X-Google-Smtp-Source: ABdhPJwgbopt4WQp0CvGW182UitmByFNQyo+N+4yDJaUVWd9lUgYEPu9ooyDKHIYPB4pIhWtEIioqvxhTavYcsqg/NA= X-Received: by 2002:a05:6214:12ab:: with SMTP id w11mr28696315qvu.42.1607453429230; Tue, 08 Dec 2020 10:50:29 -0800 (PST) MIME-Version: 1.0 References: <9e1ce2a0-cb64-067f-dc74-aa384cf34ebd@mtcc.com> In-Reply-To: <9e1ce2a0-cb64-067f-dc74-aa384cf34ebd@mtcc.com> From: Dotzero Date: Tue, 8 Dec 2020 13:50:18 -0500 Message-ID: To: Michael Thomas Cc: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="000000000000a4713305b5f86ab1" Archived-At: Subject: Re: [dmarc-ietf] p=quarantine X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 08 Dec 2020 18:50:32 -0000 --000000000000a4713305b5f86ab1 Content-Type: text/plain; charset="UTF-8" On Tue, Dec 8, 2020 at 12:42 PM Michael Thomas wrote: > > If you take the literal meaning of quarantine, that means that every > piece of email from this and every other mailing list would end up in a > quarantine folder, or some such. I'm fairly certain that is not what > people want, and I'm doubtful that many receivers implement that. The > question to my mind is whether there actually exists a state between "we > don't know" and "trash it because it's not from us". "Quarantine" seems > to mean "be more suspicious of this", but I'm not sure if that is of any > help to filters. Ultimately it's whether filters find these policies > useful is what actually matters. Don't we have enough data lying around > these days to inform us? If filters are ignoring it, then it's rather > pointless. This discussion (and many others) should be data driven, IMO. > > Mike > And here we get to some of the crucial unresolved questions involving email: "Does the wishes of a user of an account at a domain supercede the policies of the domain owner/administrator of a domain?" "Does a domain owner/administrator have the right to externalize enforcement of their internal usage policies?" These questions and associated answers go far beyond DMARC but certainly impact how one views policy statements made by DMARC. Michael Hammer --000000000000a4713305b5f86ab1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Dec 8, 2020 at 12:42 PM Micha= el Thomas <mike@mtcc.com> wrote:=

If you take the literal meaning of quarantine, that means that every
piece of email from this and every other mailing list would end up in a quarantine folder, or some such. I'm fairly certain that is not what people want, and I'm doubtful that many receivers implement that. The <= br> question to my mind is whether there actually exists a state between "= we
don't know" and "trash it because it's not from us".= "Quarantine" seems
to mean "be more suspicious of this", but I'm not sure if tha= t is of any
help to filters. Ultimately it's whether filters find these policies useful is what actually matters. Don't we have enough data lying around=
these days to inform us? If filters are ignoring it, then it's rather <= br> pointless. This discussion (and many others) should be data driven, IMO.
Mike

And here we get to some of the cru= cial unresolved questions involving email: "Does the wishes of a user = of an account at a domain supercede the policies of the domain owner/admini= strator of a domain?" "Does a domain owner/administrator have the= right to externalize enforcement of their internal usage policies?" T= hese questions and associated answers go far beyond DMARC but certainly imp= act how one views policy statements made by DMARC.

Michael Hammer
--000000000000a4713305b5f86ab1-- From nobody Tue Dec 8 11:42: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 1DFD43A1108 for ; Tue, 8 Dec 2020 11:42:42 -0800 (PST) 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 uKNnYsSEms4Z for ; Tue, 8 Dec 2020 11:42:40 -0800 (PST) Received: from mail-pf1-x431.google.com (mail-pf1-x431.google.com [IPv6:2607:f8b0:4864:20::431]) (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 919153A0365 for ; Tue, 8 Dec 2020 11:42:40 -0800 (PST) Received: by mail-pf1-x431.google.com with SMTP id q22so14847779pfk.12 for ; Tue, 08 Dec 2020 11:42:40 -0800 (PST) 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=b4AAjvG0y9e3e+rQ/copsXn7HmA1f3sDjiSoKGE+lkI=; b=Y/tMlHPmoRrQKnZ44Rf9Jx6MPlxVd80gFu9HQq/+/SbZhtG7ZKUe+cN/O/bjIofcS8 20LLgy3Tl9kC6XY+5mR4xVfE2+Ty9h5w2jTePeHAX7LPIjF+RueLQpyh96FsRd2xMHgj 1SZuVi3/YcflxMUp5/bktvi6avuznEqvE4Io2aD24O8/Tes0IkT70gWQ/ZhnSNsAMMbu 2km/pLBTCfPdPEnQer+7pnrZbZIBIXKD+0nfb4pi5bim3RsQ9BD1pPJ+MYCp2PvBXYw/ I2IW9gxKoyIkD4VPaH3go162N5yeJFqoRgBdbgvHgNDzyM7SR6MUztLXsLKEp9K2HWjP NuBA== 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=b4AAjvG0y9e3e+rQ/copsXn7HmA1f3sDjiSoKGE+lkI=; b=Hr9c3IMq4SPl4apgUpWuYj4z+S7m8NSbGaY+mI9AdfAl8aj6LVgUEa7FkC54Q2pgq2 I1W4cbungPpfOr4xFPsjjI9pmgn9BvK8D/yVJIgTKD0yv+Oj2MenbXciE5KE6p1Jjoqm 5wopzoTO0W7Wu+HFmgFvLHEIDzoZ+QlgyyLVjB4r4YM7m2qsLzA77lVm6ob+VcZz/FBj O4w9cWcniNU6e1oQNKdc5IwaADQurqqKVjFCrZ4Z2wqIhBqJPHUFqzlIaXoMVTeLAvTD OTWLZJDQEEmBwynP0io1xj9cvgbK/h7ryyBajmXadX2ZBlo4n+R+xCjI+BRdN18ibzg7 UMXw== X-Gm-Message-State: AOAM53173/j85k5MK7Og/9BJmgVOexO84YjysTeVydMlyxN0hIRWaPNK i6R6dx9fTX/GU6BvSzwon8LfqsRxbP4= X-Google-Smtp-Source: ABdhPJwEEDoLqhjLThZyiU3L6flhjSrGpNi1dZ5OJN1QR7MP1meMH0B2jbT4TpUTo3IAtcVHeqVPYA== X-Received: by 2002:a17:90a:e610:: with SMTP id j16mr5664206pjy.170.1607456559776; Tue, 08 Dec 2020 11:42:39 -0800 (PST) Received: from [192.168.0.109] (c-24-130-62-181.hsd1.ca.comcast.net. [24.130.62.181]) by smtp.gmail.com with ESMTPSA id er23sm4200268pjb.12.2020.12.08.11.42.38 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 08 Dec 2020 11:42:39 -0800 (PST) To: Dotzero , Michael Thomas Cc: "dmarc@ietf.org" References: <9e1ce2a0-cb64-067f-dc74-aa384cf34ebd@mtcc.com> From: Dave Crocker Message-ID: <3019b5f3-54d5-4ee1-02f4-c10201900d5a@gmail.com> Date: Tue, 8 Dec 2020 11:42:38 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] p=quarantine X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 08 Dec 2020 19:42:42 -0000 On 12/8/2020 10:50 AM, Dotzero wrote: > And here we get to some of the crucial unresolved questions involving > email: "Does the wishes of a user of an account at a domain supercede > the policies of the domain owner/administrator of a domain?" It's not only not crucial, it's entirely resolved, and always had been, in terms of real-world practice. The view that it hasn't been is frankly an arrogance of author domain owners. Author domain owners do not have a relationship with receivers or recipients, so their policies have no enforcement potential. Receivers and recipients are completely independent.  They do not 'override' the domain owner policies.  Rather, they apply their own policies.  Always have. This is why the language in DMARC would be far more constructive to remove any hint of attempting to direct receiver or recipient behavior, and instead merely reflect the domain owner's assessment of message validity, along the lines of the language I offered. d/ -- Dave Crocker dcrocker@gmail.com 408.329.0791 Volunteer, Silicon Valley Chapter American Red Cross dave.crocker2@redcross.org From nobody Tue Dec 8 12: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 3E1C83A1180 for ; Tue, 8 Dec 2020 12:11:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.097 X-Spam-Level: X-Spam-Status: No, score=-1.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, FREEMAIL_REPLY=1, HTML_MESSAGE=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 jftfSuiv6U2i for ; Tue, 8 Dec 2020 12:11:54 -0800 (PST) Received: from mail-qt1-x830.google.com (mail-qt1-x830.google.com [IPv6:2607:f8b0:4864:20::830]) (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 0F49B3A1183 for ; Tue, 8 Dec 2020 12:11:48 -0800 (PST) Received: by mail-qt1-x830.google.com with SMTP id z3so12864198qtw.9 for ; Tue, 08 Dec 2020 12:11:48 -0800 (PST) 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=Wlz5VxspEbqEkaNp76rGisHRA9XokKrGeBT+JM9a838=; b=hd4GSSFJQQjb84TMcmYd5PJfiytNwrIB3fW9S0bl+FJncyOpAcKsXNpPWBDDMLNRKt Xr9U75oF5f1c93LgiLwWDo4Gh3qsWNfAyV4A3+dJhE0RkflJXxFNHJ3Vp7UplglGvBTO 6A3jGHJ3GYoMvTd0TCfR2NnXc4TVx9fTuLQtfC4GP7R9ePH6h3EM8Mp28LH8gH8tkinf AWCdEfzhEu8PYigwVLpNizglgzWKTBPmn3+nI59bJ501Y+zimnmrF/yPcNF8uEDWueLA DUT8iD8Ol8+cAE+cbjGU+UrbY1OmmvFLVJF9VPUoTH8OgsxyUz+zW2uPqFTy0s82abaS bPEw== 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=Wlz5VxspEbqEkaNp76rGisHRA9XokKrGeBT+JM9a838=; b=k+AreAKn/iIEX1v61PV5Y/fWEDJlc+u5JnvcGpGeu+4Nuq2NRk9JGk//lB91/bwtjO YYH9HQhCf+YCN3QKaO1pw/NlQ3EH8NqHlTtGGuwsBhpH9t9TMlRWnRmNH/DKrt0g3ThQ gzfhJradhLfNkmnSa2mMMJu85QuLcdpz8WKF2Ei4c8WAXxP3nzM9pgEhWzRCXQ88A8st ZLyzvJlWOfqPGrqZGdUDJfJ9DQoBA5xk9RwZ9kTZLSoVUZPmjkZnyPiA81OLXKOKALGp Xz+9qja/jfbbUUsaTlLRv4bdIA81CoujEfPLibe48LS6b/MyDtaAshZM7qsdUbbugSzX t8nA== X-Gm-Message-State: AOAM530+jdfz90TQLE41kO5kLevOR08NqPsDk17DZ6wbCaGYOttT62Ag IuEYoU1/YcAG8/K3QDoca5P3mkbVcnACj6fPUB4= X-Google-Smtp-Source: ABdhPJz319xTNWk5IW4afUmgL0fIfx5x1d67rHOS9OYLHVuTXW0XZfF8Z6ud4JRMmfa7suJ6xwxUJq0LMoLMzQJkvsk= X-Received: by 2002:ac8:5d53:: with SMTP id g19mr32444612qtx.354.1607458308029; Tue, 08 Dec 2020 12:11:48 -0800 (PST) MIME-Version: 1.0 References: <9e1ce2a0-cb64-067f-dc74-aa384cf34ebd@mtcc.com> <3019b5f3-54d5-4ee1-02f4-c10201900d5a@gmail.com> In-Reply-To: <3019b5f3-54d5-4ee1-02f4-c10201900d5a@gmail.com> From: Dotzero Date: Tue, 8 Dec 2020 15:11:37 -0500 Message-ID: To: Dave Crocker Cc: Michael Thomas , "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="00000000000070ff9305b5f98d66" Archived-At: Subject: Re: [dmarc-ietf] p=quarantine X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 08 Dec 2020 20:12:03 -0000 --00000000000070ff9305b5f98d66 Content-Type: text/plain; charset="UTF-8" Note that I asked Two questions. Your answer appears directed to the second question. The answer to the first question appears fairly clear to me. Administrators of a system can restrict or delete a user account. It really is as simple as that. So in that respect the answer is that ultimately an individual account users do not supersede the wishes/policy of the domain owners representatives. The second question is a bit more interesting, but ultimately leads one back to the first question. As far as being long settled, I would think that NSF AUP is an interesting precedent. Michael Hammer On Tue, Dec 8, 2020 at 2:42 PM Dave Crocker wrote: > On 12/8/2020 10:50 AM, Dotzero wrote: > > And here we get to some of the crucial unresolved questions involving > > email: "Does the wishes of a user of an account at a domain supercede > > the policies of the domain owner/administrator of a domain?" > > It's not only not crucial, it's entirely resolved, and always had been, > in terms of real-world practice. The view that it hasn't been is frankly > an arrogance of author domain owners. > > Author domain owners do not have a relationship with receivers or > recipients, so their policies have no enforcement potential. Receivers > and recipients are completely independent. They do not 'override' the > domain owner policies. Rather, they apply their own policies. Always > have. > > This is why the language in DMARC would be far more constructive to > remove any hint of attempting to direct receiver or recipient behavior, > and instead merely reflect the domain owner's assessment of message > validity, along the lines of the language I offered. > > d/ > > -- > Dave Crocker > dcrocker@gmail.com > 408.329.0791 > > Volunteer, Silicon Valley Chapter > American Red Cross > dave.crocker2@redcross.org > > --00000000000070ff9305b5f98d66 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Note that I asked Two questions. Your answer appears = directed to the second question. The answer to the first question appears f= airly clear to me. Administrators of a system can restrict or delete a user= account. It really is as simple as that. So in that respect the answer is = that ultimately an individual account users do not supersede the wishes/pol= icy of the domain owners representatives.

The seco= nd question is a bit more interesting, but ultimately leads one back to the= first question. As far as being long settled, I would think that NSF AUP i= s an interesting precedent.

Michael Hammer
=

On Tue, Dec 8, 2020 at 2:42 PM Dave Crocker <dcrocker@gmail.com> wrote:
On 12/8/2020 10:50 AM, Dotzero wrote: > And here we get to some of the crucial unresolved questions involving =
> email: "Does the wishes of a user of an account at a domain super= cede
> the policies of the domain owner/administrator of a domain?"

It's not only not crucial, it's entirely resolved, and always had b= een,
in terms of real-world practice. The view that it hasn't been is frankl= y
an arrogance of author domain owners.

Author domain owners do not have a relationship with receivers or
recipients, so their policies have no enforcement potential. Receivers
and recipients are completely independent.=C2=A0 They do not 'override&= #39; the
domain owner policies.=C2=A0 Rather, they apply their own policies.=C2=A0 A= lways have.

This is why the language in DMARC would be far more constructive to
remove any hint of attempting to direct receiver or recipient behavior, and instead merely reflect the domain owner's assessment of message validity, along the lines of the language I offered.

d/

--
Dave Crocker
dcrocker@gmail.com<= /a>
408.329.0791

Volunteer, Silicon Valley Chapter
American Red Cross
dave.crocke= r2@redcross.org

--00000000000070ff9305b5f98d66-- From nobody Tue Dec 8 12:26: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 9832B3A11A1 for ; Tue, 8 Dec 2020 12:25:55 -0800 (PST) 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 B9JDYZTbwNoL for ; Tue, 8 Dec 2020 12:25:53 -0800 (PST) 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 63F863A116E for ; Tue, 8 Dec 2020 12:25:52 -0800 (PST) Received: from localhost.junc.eu (localhost.junc.eu [127.0.0.1]) by mx.junc.eu (Postfix) with SMTP id 629767FFAE for ; Tue, 8 Dec 2020 20:25:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junc.eu; i=@junc.eu; l=713; q=dns/txt; s=default; t=1607459151; h=from : subject : date : to; bh=Vz029dUQOGo1SeB0Um94MCe9BQTNOgO1u2rqTstIej0=; b=NibsfrZ0SV7whUnsQFPAgN93taRc1cFI4NZqUXGbwjT67Bjg8bD9LNoH130won2W3TmJ/ 8x3rEXGwZ4QNsPgYwt2PF2uVryPIhhPiDaJeDeq794wHYOZSMdeJyEXT5fHEYrgF4V0Toj+ pDXHSIQlWfDUV+eeKTPz5/g21FIowxM= Received: from localhost.junc.eu (localhost.junc.eu [IPv6:::1]) by mx.junc.eu (Postfix) with ESMTPSA id 45B2F7FB78 for ; Tue, 8 Dec 2020 20:25:51 +0000 (UTC) MIME-Version: 1.0 Date: Tue, 08 Dec 2020 21:25:51 +0100 From: Benny Pedersen To: dmarc@ietf.org In-Reply-To: References: <9e1ce2a0-cb64-067f-dc74-aa384cf34ebd@mtcc.com> User-Agent: Roundcube Webmail/1.4.8 Message-ID: <46aee46c2298f10c3f3c4893164d6b40@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] p=quarantine X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 08 Dec 2020 20:26:03 -0000 Dotzero skrev den 2020-12-08 19:50: > And here we get to some of the crucial unresolved questions involving > email: "Does the wishes of a user of an account at a domain supercede > the policies of the domain owner/administrator of a domain?" "Does a > domain owner/administrator have the right to externalize enforcement > of their internal usage policies?" These questions and associated > answers go far beyond DMARC but certainly impact how one views policy > statements made by DMARC. i have solved it by using fuglu :=) when i used milters in postfix i just did that in postfix to tell dont use milters on maillists ips, pretty simple but there might be more options, eq dont break dkim From nobody Tue Dec 8 12:29: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 649763A07F0; Tue, 8 Dec 2020 12:29:33 -0800 (PST) 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, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XIqykzTHtUTi; Tue, 8 Dec 2020 12:29:31 -0800 (PST) Received: from mx0a-00143702.pphosted.com (mx0a-00143702.pphosted.com [148.163.145.77]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 335103A07EA; Tue, 8 Dec 2020 12:29:28 -0800 (PST) Received: from pps.filterd (m0184892.ppops.net [127.0.0.1]) by mx0a-00143702.pphosted.com (8.16.0.43/8.16.0.43) with SMTP id 0B8KN9NH031580; Tue, 8 Dec 2020 15:29:27 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=20190412; bh=bYTRYkZF4RPvyGgk3AWfX7/Cb/dRXTQx2TTPswS3Q/M=; b=F3I+aMitQwKQJdKAP1ZEYq38GERD1IwbDmVO27y0BPavZESxy4ZIETv9gySGzdy/kg05 UhbcawGr4ZYIME4zLkuCCFxQRggIW13z2n6lO7WIMYfZxn0z/mFjjim/aPVdiDquod4a 63RBeN5WYHvlLIJxrh35ZRWGxfLKq45bTZQ6U+L2QMeGwOKB4vmPwZJcmQ6cU3qbovd7 94HD0GlaPV+ZwC0l80Gt0DhOZQlOziQPzzSwQhDQkRcPKrtdzcPrGUFaUYsEaUlAmzNx 5xrA2NaO0DFI2dRUTUDwycfUydkPF02Hne9ENKSQWpDawahP1e5WHTKbjEie+AqfSR5q 6g== Received: from pacdcex51.cable.comcast.com (dlppfpt-wc-1p.slb.comcast.com [96.99.226.136]) by mx0a-00143702.pphosted.com with ESMTP id 3587huu6vt-3 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 08 Dec 2020 15:29:27 -0500 Received: from PACDCEX49.cable.comcast.com (24.40.2.148) by PACDCEX51.cable.comcast.com (24.40.2.150) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 8 Dec 2020 15:29:22 -0500 Received: from PACDCEXEDGE01.cable.comcast.com (76.96.78.71) by PACDCEX49.cable.comcast.com (24.40.2.148) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Tue, 8 Dec 2020 15:29:22 -0500 Received: from NAM11-DM6-obe.outbound.protection.outlook.com (104.47.57.175) by webmail.comcast.com (76.96.78.71) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 8 Dec 2020 15:29:10 -0500 Received: from MN2PR11MB4351.namprd11.prod.outlook.com (2603:10b6:208:193::31) by BL0PR11MB2882.namprd11.prod.outlook.com (2603:10b6:208:7f::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3632.17; Tue, 8 Dec 2020 20:29:09 +0000 Received: from MN2PR11MB4351.namprd11.prod.outlook.com ([fe80::7ca6:b482:a6b0:4d42]) by MN2PR11MB4351.namprd11.prod.outlook.com ([fe80::7ca6:b482:a6b0:4d42%7]) with mapi id 15.20.3632.021; Tue, 8 Dec 2020 20:29:09 +0000 From: "Brotman, Alex" To: Marc Bradshaw , DMARC IETF Thread-Topic: [dmarc-ietf] Discussion - ARC/Extensible Reporting (Ticket #56) Thread-Index: AdbI4+CbIMDOrFacSCuqUWajtLQ8TwAgvwMAAA97pBAAAfRzAADOhtAAAC42nxA= Date: Tue, 8 Dec 2020 20:29:09 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dmarc.ietf.org; dkim=none (message not signed) header.d=none; dmarc.ietf.org; dmarc=none action=none header.from=comcast.com; x-originating-ip: [2601:43:101:380:b8f0:f8ea:7aa9:61ad] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 711725fa-7924-41b1-d177-08d89bb7eab4 x-ms-traffictypediagnostic: BL0PR11MB2882: 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: /IwylYeve2kCmYU3AGuJ1MhXUTJtOUTtXqQ4ixx9JeklyPrZE4JMfIP2NwhJJlw9q+GzkdEch2lNyO8dX66bn/8J+u9kteBxxDFrEXL9XRox3K2kr+gjackKittT89SVI7p5BPoEWVzAc2n1S0GIJgDJ4GoXAUF/43Wphe1KVSPsxmi8GwW85jUDkPXyt4FNs1X/dSfPaCLbAD9dMAqRhRSHgjJRF7VzLH+/FWPC1SThmbZiou+DuAIEQmKn+2+w3npvTdoSSjzK22pZqW+Tf3g3WVhn+9UXyIfY04rI+TXOdfhjzGSFvgBwyXWKGpALCEA0x8dyEXF+ncjnosxVdfuCFg70iq+JfdC7c7suPmtSf6wRxmwl5FPjRZcl5pMT9otFN1c12FAMBZjh7GyHvA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR11MB4351.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(376002)(346002)(136003)(66476007)(166002)(8676002)(55016002)(9686003)(52536014)(71200400001)(966005)(508600001)(186003)(8936002)(53546011)(86362001)(2906002)(110136005)(7696005)(83380400001)(6506007)(66556008)(76116006)(66946007)(64756008)(66446008)(5660300002)(33656002); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: =?us-ascii?Q?PDL2gBe6Fj5U1wHXcfAUGzyGjBqf3WyFbq+ryy5qZhNl7xXNVf6hU7K0QuOD?= =?us-ascii?Q?KG9kcSnv8wui3MVaaLp4Jnj5brBj++93Svso5gsajB+UfaUoKvJVIB3QgvgS?= =?us-ascii?Q?a4NwiPxay3Owfm10swDg4VhdHKp3nxNJUO93TAGo8CoYnCxxhWLthl4zb9Kj?= =?us-ascii?Q?mn1+4K00TuerBE/8z4D2IRhEi6xoEn72hRMNooiVykjYSIjaketKfVYzk7se?= =?us-ascii?Q?tEOiG5gsh9MoksGcr23pjBu8s2aoKcBrnH1zEazAHam0AP/qCH24ioU0z9VO?= =?us-ascii?Q?wCdbhWvhTHSz6B3LDl65Ma5BXP/DxWfvboLjeRU1T2KxS4lZaWXsHYTwXREx?= =?us-ascii?Q?vCNMpsjkLMDcyL9gSzcBjn8fkDCC+jVsayV8v8VaT3flKlShMJ3gLOWsuFWa?= =?us-ascii?Q?HUWjlh8ETnZMvYZeLeADW18fh1i8SdmAiLV/CiZjp3VywbqajMZSNiJmmd4S?= =?us-ascii?Q?4F21x4JhY/HkkSVa5p0E8QKkDjoGIzDBPxiZwcwA8I0XVinb3kjyLZyCblaM?= =?us-ascii?Q?0k7PTTjPymElHmkKBzIR6G0MXttWxYnrs7kXV8kK6wI/lU7sLHpfyoUjvjzL?= =?us-ascii?Q?T2YqDCU3gXI6lKAoy0y4sjvL7j4CyHxbC1jSpMAXnNgI1JT37xbYRkcdUGST?= =?us-ascii?Q?fW7pc1qX0BLnmsCUiBrY4xGHaurtcZ1EjdER4gkWSdljJKkiP0MKX1vZL1Y8?= =?us-ascii?Q?2aVYgUOJt711Frp24YdtnbDH8fQW93vhF56BI6xsl/lY1c8VDq3VQcTXUl2g?= =?us-ascii?Q?36PhLZ1CV0AslQ2gf5naUh0Wgum86Iqs8qBNwtdA29rK9wbkN7d+SKeRCz33?= =?us-ascii?Q?meKHOMtIIC7q4Pq4qPAEDrZoSHxN1q9/zvN0r5x73nxQdliUiMtyNHisqdQy?= =?us-ascii?Q?ndjmLq9YnFTXHeRcLlTaUwRF/IdZrUibhEUXH9tkcHm5PwwDv16zNV0GGgcW?= =?us-ascii?Q?U8k47kfUIlVTxje7ooR2k+ENJX1CQnAy3LugEprvrlWAQ5jQR5SbQ+CfUAbd?= =?us-ascii?Q?+QubReM/uABCMCH4z/0j1wLMIWEFXKGM2GyDCq1QYPLydCc=3D?= x-ms-exchange-transport-forked: True arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=jiooas0TGPnq/2sdJ20ayvThVDmw3rKcHmFIiKdwXY6EYiFJ+FDCf6cnytQCw1eluXHqr96V9ox3gxKDhoWwnqEt/fSeHvfdrp2p8Q4hlzgE1J0WsjjCCQDeyCARcJi0PGS/N9MKMaFyGbGZo4XfhE4UrHMoCfpur4x2TCvt0Vn0w9CMBhO418ePPgc9LSJze+9FWHlUW6OD89a2ZvFMyEtVpb2ZAmdmwiglqwW8JyyvzgpQ6vIV0dZPGRyu1K9WuIDLwWuDyKSjRMdsHUUUfZ6hUaaNOLac8MUJyX1rj4C+jbY4eWwcynG4Mh3Fv4UbrDtJ2iEF8r3qy4TnQWVpcQ== 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=DmXDqH5D/dhgIoQ8xasbPW/q7ruRDFWhd4EzucRHSow=; b=AWVSkoyXe1NWGlCKRNaF/ohx84hn0ca8u4IhV/7ZNTIUonFw1qQAudZgi45J5rLofPqnF3hLIGVuA8q7u7oqREpBDcmPcVSmVEWIRkAYkG2l1wCORks8WDapNae20pJLYB/Z/bVtrmsUy56gp2fQa63P/PXUjNvuHnKOd4R/h+GvxELT0rAmJRE4bzbM6Afi2358xfrrALNAop3hLekD/UOxKznoSNc7OLp3b1gH695/Vnko4CO1yEpZKjlpeX0PJ2dpDeqeFBVZfTQK2gTqndY/PHaJ2mTOsjG1xbucBcrRYC01YmrN6XEFs6L3JLEHUrTeCIvOmpw6Wb4eoAYaOQ== arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=comcast.com; dmarc=pass action=none header.from=comcast.com; dkim=pass header.d=comcast.com; arc=none x-ms-exchange-crosstenant-authas: Internal x-ms-exchange-crosstenant-authsource: MN2PR11MB4351.namprd11.prod.outlook.com x-ms-exchange-crosstenant-network-message-id: 711725fa-7924-41b1-d177-08d89bb7eab4 x-ms-exchange-crosstenant-originalarrivaltime: 08 Dec 2020 20:29:09.0994 (UTC) x-ms-exchange-crosstenant-fromentityheader: Hosted x-ms-exchange-crosstenant-id: 906aefe9-76a7-4f65-b82d-5ec20775d5aa x-ms-exchange-crosstenant-mailboxtype: HOSTED x-ms-exchange-crosstenant-userprincipalname: n/LC1Z3HJKWJGsgtUZU6V3062m9elg/vOaSj14Cz/b4GROSig62Jssb8zeTQssXmWwhXFHVO4/avQPLoJYumJwj4g2lqfIGbd2MXxorpQDE= x-ms-exchange-transport-crosstenantheadersstamped: BL0PR11MB2882 x-originatororg: comcast.com Content-Type: multipart/alternative; boundary="_000_MN2PR11MB43511AD9A2B8C6CF1356491DF7CD0MN2PR11MB4351namp_" MIME-Version: 1.0 X-CFilter-Loop: Forward AAETWS X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.343, 18.0.737 definitions=2020-12-08_15:2020-12-08, 2020-12-08 signatures=0 X-Proofpoint-Spam-Reason: safe Archived-At: Subject: Re: [dmarc-ietf] Discussion - ARC/Extensible Reporting (Ticket #56) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 08 Dec 2020 20:29:33 -0000 --_000_MN2PR11MB43511AD9A2B8C6CF1356491DF7CD0MN2PR11MB4351namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I feel (as a receiver of reports) as though another reason to have these as= a single report is so that the receiver of the report is able to more easi= ly correlate the data/times. I should be able to believe that all reports = (without a specified ri) will be 0000-2359, though things happen, and syste= ms break down. -- Alex Brotman Sr. Engineer, Anti-Abuse & Messaging Policy Comcast From: dmarc On Behalf Of Marc Bradshaw Sent: Monday, December 7, 2020 5:17 PM To: DMARC IETF Subject: Re: [dmarc-ietf] Discussion - ARC/Extensible Reporting (Ticket #56= ) There is value in including these in one report, especially where the exten= ded property being reported on influences how DMARC is evaluated. Using ARC as the example, when a p=3Dreject policy was overriden by the rec= eiver because of an ARC evaluation, when that data is included in the repor= t the indirect mail flow can be clearly seen, which would not be the case i= f ARC were included as a separate report. This could be included in an element, or could be included dire= ctly in the auth_results section of the report, based on an assumption that= the things being reported SHOULD have an authentication results entry in p= rocessed mail. ... ... (as defined in arc standard) (as defined in foo standard) These would be defined in a registry with reference to each standard, and p= arsers would ignore any sections they did not understand. On Fri, 4 Dec 2020, at 6:43 AM, Alessandro Vesely wrote: On Thu 03/Dec/2020 19:54:51 +0100 Brotman, Alex wrote: > >> -----Original Message----- >> From: dmarc > On B= ehalf Of Alessandro Vesely >> Sent: Thursday, December 3, 2020 6:24 AM >> To: dmarc@ietf.org >> Subject: Re: [dmarc-ietf] Discussion - ARC/Extensible Reporting (Ticket = #56) >> >> On Wed 02/Dec/2020 20:46:54 +0100 Brotman, Alex wrote: >>> >>> While this ticket/enhancement specifically mentions ARC, I could >>> perhaps see the usefulness in other places. It seems like it would be >>> more beneficial to create a method by which other documents could >>> provide XML- based "extensions" to the report. This would allow >>> mechanisms relying on DMARC to independently define their reporting >>> schema to be included in DMARC aggregate reports. Alternately, we coul= d >>> focus specifically on ARC, and work to include that in the base XML. >>> This means that any later reporting requirements could again require >>> changes to the core drafts.>>> >> >> >> Another possibility is for ARC to define its own report format. Hijacki= ng >> rua=3D targets to send a different kind of report should be allowed. >> Otherwise, we could define a new tag, e.g. rue=3D (e for Extension).>> >> In either case, as we're introduce variations in aggregate report conten= t, >> we have to devise a method for determining what version/kind of report i= s >> attached to a given message.>> > > We could add an element called "", and we allow ARC or whatev= er > it may be to exist under that element. The Aggregate Reporting document > needs to specify that any extensions are expected to be proper XML, and i= f > there are no extensions, an empty element is sufficient. We could create= a > bit more structure as a requirement if we wanted:> > > > ... (as defined in referenced standard) > > > > If a report parser doesn't know what ARC is (or any of the extensions), i= t could skip the processing. I do understand this means that = element may break existing parsers, even when empty, though, I expect many = of the things we're proposing may fracture the expected XML. We can do a better job at producing aggregate reports with an automatically= verifiable content. For example, prepending stuff like this: " xmlns:dmarc=3D"http://dmarc.org/dmarc-xml/0.1" xs:schemaLocation=3D"http://dmarc.org/dmarc-xml/0.1 rua.xsd"> ... (Perhaps something better than "http://dmarc.org/dmarc-xml/0.1" for the version) But then, would the imply dmarc-xml grammar should be upgraded= every time ARC (or whatever) is upgraded? Separate reports sounds simpler. Best Ale -- _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc -- [https://secure.gravatar.com/avatar/b214a020f4eb135ce2a6901d7540bdb1?s=3D44= &d=3D404] Marc Bradshaw marcbradshaw.net | @marcbradshaw --_000_MN2PR11MB43511AD9A2B8C6CF1356491DF7CD0MN2PR11MB4351namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I feel (as a receiver of reports) as though another = reason to have these as a single report is so that the receiver of the repo= rt is able to more easily correlate the data/times.  I should be able = to believe that all reports (without a specified ri) will be 0000-2359, though things happen, and systems break d= own.

 

--

Alex Brotman

Sr. Engineer, Anti-Abuse & Messaging Policy=

Comcast

 

From: dmarc <dmarc-bounces@ietf.org> On Behalf Of Marc Bradshaw
Sent: Monday, December 7, 2020 5:17 PM
To: DMARC IETF <dmarc@ietf.org>
Subject: Re: [dmarc-ietf] Discussion - ARC/Extensible Reporting (Tic= ket #56)

 

 

There is value in including these in one report, esp= ecially where the extended property being reported on influences how DMARC = is evaluated.

 

Using ARC as the example, when a p=3Dreject policy w= as overriden by the receiver because of an ARC evaluation, when that data i= s included in the report the indirect mail flow can be clearly seen, which = would not be the case if ARC were included as a separate report.

 

This could be included in an <extension> eleme= nt, or could be included directly in the auth_results section of the report= , based on an assumption that the things being reported SHOULD have an auth= entication results entry in processed mail.

 

<auth_results>

<dkim>...</dkim>

<spf>...</spf>

<arc> (as defined in arc standard) </arc>=

<foo> (as defined in foo standard) </foo>=

</auth_results>

 

These would be defined in a registry with reference = to each standard, and parsers would ignore any sections they did not unders= tand.

 

On Fri, 4 Dec 2020, at 6:43 AM, Alessandro Vesely wr= ote:

On Thu 03/Dec/2020 19:54:51 +0100 Brotman, Alex = wrote:

> 

>> -----Original Message-----

>> From: dmarc <dmarc-bounces@ietf.org> On Behalf Of Alessandro Vesel= y

>> Sent: Thursday, December 3, 2020 6:24 AM

>> Subject: Re: [dmarc-ietf] Discussion - ARC/= Extensible Reporting (Ticket #56)

>> 

>> On Wed 02/Dec/2020 20:46:54 +0100 Brotm= an, Alex wrote:

>>> 

>>> While this ticket/enhancement specifica= lly mentions ARC, I could

>>> perhaps see the usefulness in other pla= ces.  It seems like it would be

>>> more beneficial to create a method by w= hich other documents could

>>> provide XML- based "extensions&quo= t; to the report.  This would allow

>>> mechanisms relying on DMARC to independ= ently define their reporting

>>> schema to be included in DMARC aggregat= e reports.  Alternately, we could

>>> focus specifically on ARC, and work to = include that in the base XML.

>>> This means that any later reporting req= uirements could again require

>>> changes to the core drafts.>>>=

>> 

>> 

>> Another possibility is for ARC to define it= s own report format.  Hijacking

>> rua=3D targets to send a different kind of = report should be allowed.

>> Otherwise, we could define a new tag, e.g. = rue=3D (e for Extension).>>

>> In either case, as we're introduce variatio= ns in aggregate report content,

>> we have to devise a method for determining = what version/kind of report is 

>> attached to a given message.>>

> 

> We could add an element called "<extens= ions>", and we allow ARC or whatever

> it may be to exist under that element.  Th= e Aggregate Reporting document

> needs to specify that any extensions are expect= ed to be proper XML, and if

> there are no extensions, an empty element is su= fficient.  We could create a

> bit more structure as a requirement if we wante= d:> 

> <extensions>

>    <extension name=3D"ar= c" standard=3D"ARC_DMARC_REPORTING_EXTENSION_DEFINITION">=

>      ... (as defined i= n referenced standard)

>    </extension>=

> </extensions>

> 

> If a report parser doesn't know what ARC is (or= any of the extensions), it could skip the processing.  I do understan= d this means that <extensions> element may break existing parsers, ev= en when empty, though, I expect many of the things we're proposing may fracture the expected XML.

 

 

We can do a better job at producing aggregate report= s with an automatically verifiable content.  For example, prepending s= tuff like this:

 

<?xml version=3D"1.0" encoding=3D"= UTF-8"?>

<dmarc:feedback xmlns:xs=3D"= http://www.w3.org/2001/XMLSchema-instance"

xs:schemaLocation=3D"http://dmarc.org/dmar= c-xml/0.1 rua.xsd">

<report_metadata>

        ...<= /o:p>

 

(Perhaps something better than "http://dma= rc.org/dmarc-xml/0.1" for the version)

 

But then, would the <extensions> imply dmarc-x= ml grammar should be upgraded every time ARC (or whatever) is upgraded?

 

Separate reports sounds simpler.

 

 

Best

Ale

-- 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

_______________________________________________=

dmarc mailing list

 

 

--

  Marc Bradshaw

 

 

--_000_MN2PR11MB43511AD9A2B8C6CF1356491DF7CD0MN2PR11MB4351namp_-- From nobody Tue Dec 8 15:56: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 32CC73A0C73 for ; Tue, 8 Dec 2020 15:56:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.851 X-Spam-Level: X-Spam-Status: No, score=-1.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iecc.com header.b=j+CUNw8m; dkim=pass (2048-bit key) header.d=taugh.com header.b=Of15cOzd Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UTz3TXvQalIO for ; Tue, 8 Dec 2020 15:56:29 -0800 (PST) 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 C45B33A0C70 for ; Tue, 8 Dec 2020 15:56:28 -0800 (PST) Received: (qmail 92396 invoked from network); 8 Dec 2020 23:56: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:cleverness; s=168ea.5fd012a8.k2012; bh=NMSbsEqwEu+AUdg4r514zmXd+GIH8DrfZPr1mOwXY1E=; b=j+CUNw8mHhYjMhf84TQF7kQo948IjW6/TM0x5wpttlZ1DQk1B4bIRzqu9NjRI3EJ6j2+2ky8GCUpBVYfuQnXyNJzTCv955wFWwfzoD4wLyGPNgjRomRN9UiHTZMQu/mqH8BcOCLOT8mpP9GpbZyWq1gYgCR0XHC/6eAFAPXrqaXhiPXvDMpFY6zFtBLEtOhGmSMTyBgbK7Cas11WgSZ79ZkfMwERqU0rlxDUgylJ2BKT0YBMXshZGG23qV3/caIy2tQmfyAGllbZatyV9Lw7ycJMsfuaQtA8ZFCmx6y4x/6tQOWM5biCcMHzgSBQmDM4SgXB8K4fqUXK9kMAzijH1g== DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=168ea.5fd012a8.k2012; bh=NMSbsEqwEu+AUdg4r514zmXd+GIH8DrfZPr1mOwXY1E=; b=Of15cOzdkXnk5j6NdBd/ctI6G2i1zt6G7pPaTBNUjPafn4EAScQ4YApsF6FTxFlWogLVxDRD3dmwqcXWzr8bigaic0L1i2b/XtJM/UpyyN1AmdeX5zF24Z2DhCgY3dce88dgZP8q9QLlD23TDRymjQtHiD5GquaRmzIwc0N8i6kzWX6xPFDH/P+cIxXz32bWDH7TgEmR3N8zOAEJ3JGP+1IPD26xnHM18JWEkPkRnLAOtmsTw/fMaCcLn9ufTJ2QKzJB6PK3m91sDaKNGGhVyZbqXs2p0kyrk+okbfqHVa4hvgGGW3/00Sj93rhKw8QUwo74W9r9ih67/dHI344qNg== Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2 ECDHE-RSA AES-256-GCM AEAD) via TCP6; 08 Dec 2020 23:56:23 -0000 Received: by ary.qy (Postfix, from userid 501) id 77A662938D42; Tue, 8 Dec 2020 18:56:22 -0500 (EST) Date: 8 Dec 2020 18:56:22 -0500 Message-Id: <20201208235623.77A662938D42@ary.qy> From: "John Levine" To: dmarc@ietf.org Cc: johnl@taugh.com In-Reply-To: Organization: Taughannock Networks X-Headerized: yes Cleverness: minimal Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] Ticket #42 - Expand DMARC reporting URI functionality X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 08 Dec 2020 23:56:31 -0000 In article you write: >>> I didn't get any of those (the POSTs below are not to the right URI) >>> but it's impressive how fast Russian bots started to probe it, within >>> hours. >> >> I thought it's about interoperability. Simply having a webserver running >> doesn't come close to interoperability, and certainly not at scale. > >I guess I wasn't clear enough. I know there's no http reporting in DMARC, >but there was in an early version of the spec. I was wondering if anyone >had implemented that. Apparently not. I must admit one thing that did surprise me was that something is looking at DMARC DNS records and probing the https URIs they contain, since that is the only place there are referecnes to my newly created https reporting URI. R'sm John From nobody Tue Dec 8 16: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 CA9513A139A for ; Tue, 8 Dec 2020 16:00:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.85 X-Spam-Level: X-Spam-Status: No, score=-1.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iecc.com header.b=Xe3K0U4B; dkim=pass (2048-bit key) header.d=taugh.com header.b=TkXns0ao Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 07eYcNNjejfP for ; Tue, 8 Dec 2020 16:00:45 -0800 (PST) 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 7377A3A13B5 for ; Tue, 8 Dec 2020 16:00:45 -0800 (PST) Received: (qmail 93481 invoked from network); 9 Dec 2020 00:00:44 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=16d26.5fd013ac.k2012; bh=ibV2xaxR8cCwPvdhN31PzfUWltQEJO5Lr5BICij/4J4=; b=Xe3K0U4BhORmPhdNEpTfsM4fcVr8EbbKD32oMv7JToRrg9XaOGrieiBhqUwc6GRKJ8Zgx4KFO6liXvu+tLEAOSI927/KUnSZUKaHWOCZuS4FHdQJ131n68b40gQS0f7Q7EMEwPhwUawzKMVfI3W3Yt75Ak3mIJ1cxI5u41HxSipUnyxIX8XRaAmLRDlibU6/UELxzvmUvYJHhjsEjRIPCc6R5gcxkfTXvuYzHj9Pa34w1GPRfluACcadRkNBy0SBXAV4I7pllwVoOfJc2OdfejXCNGksyWKoBeiHNkgvtiePe/jhLfleDv+n34sJcg2cbaA2okgDT9ZFNJxnAbdthg== DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=16d26.5fd013ac.k2012; bh=ibV2xaxR8cCwPvdhN31PzfUWltQEJO5Lr5BICij/4J4=; b=TkXns0aoFqDPJkkyFn2Fv7oDD+DMS8FM2KsabWpSTKoD+nMX6B5YLTG6YMOnkEn/XzCcap4bFnVf5l6+rgRhbvCNSqwL7dS+yxk4NzlfJopJ8RKa1Tc2FffnK65ZzYrtpt5UWVSlFpMngMBDrSePciHdCF/STXbBxJ52NVea7/CXOOcH2ZW2bW9Wv9EIA3Jz01FIt0jd9es58HYLE/ssa0I1A+0X13HGpN9NfBm3E/Gbd/9gOcc5/HZgRvt4xoALdZcuYjnAqSPVaImZl+QS0K7lcbgjzW6mW73EWhffdrHqH9QMF5z1xdaNEukT0qC+9Tn/04WhNZBoZ9xtQbb2eQ== 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; 09 Dec 2020 00:00:43 -0000 Received: by ary.qy (Postfix, from userid 501) id 482C62938E82; Tue, 8 Dec 2020 19:00:42 -0500 (EST) Date: 8 Dec 2020 19:00:42 -0500 Message-Id: <20201209000043.482C62938E82@ary.qy> From: "John Levine" To: dmarc@ietf.org Cc: dotzero@gmail.com In-Reply-To: Organization: Taughannock Networks X-Headerized: yes Cleverness: minimal Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] p=quarantine X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 09 Dec 2020 00:00:56 -0000 In article you write: >-=-=-=-=-=- > >Note that I asked Two questions. Your answer appears directed to the second >question. The answer to the first question appears fairly clear to me. >Administrators of a system can restrict or delete a user account. It depends what agreements they might have with the users but in general I agree, users can only do what their system managers permit. >The second question is a bit more interesting, but ultimately leads one >back to the first question. As far as being long settled, I would think >that NSF AUP is an interesting precedent. Huh? NSFNET shut down decades ago. I would be surprised if its agreements with the systems it served, all of which had some contractual relationship with the NSF, had any relevance beyond a tiny handful of government funded academic networks. R's, John From nobody Tue Dec 8 16:04: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 5B4383A138B for ; Tue, 8 Dec 2020 16:04:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.851 X-Spam-Level: X-Spam-Status: No, score=-1.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iecc.com header.b=Qm3XusOq; dkim=pass (2048-bit key) header.d=taugh.com header.b=DmTtDUlu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2d--CkpXm9aE for ; Tue, 8 Dec 2020 16:04:54 -0800 (PST) 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 1728B3A1384 for ; Tue, 8 Dec 2020 16:04:48 -0800 (PST) Received: (qmail 94280 invoked from network); 9 Dec 2020 00:04:47 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=17043.5fd0149f.k2012; bh=XqAENsmfTSehf7nt97YUxDrI+Otsf83SZtgy0X8H3kM=; b=Qm3XusOq+A95Bbzf4bOVQqz8nRWrE5LHwb39CDhpB4V4imQRR0TBLVAXInRjSJvDty1yNWCYcx0rdj+2te96alTfI4DvWQi2bK9qK4Midzw617uO69rBfTIwTb+mW0Y9SYl95kLb0IgmRgQXnAppepryerS14DQJSSedfs8zQefsOxY0EB1etTW//Yt71eC2gdX43sc8j+OgQwQMF8mW7t00hxCWAAMrwye+SJyOoWYpYE2f2fiAn1Fe/GSkjJxkxGe4bWqcLHNR1ej5q35rB0UldiKNXrGM/Atc1PnmXqHKGPXu33dJGDZbreSwpUpYsEk7oQB2mXxIqUlEbmm6oA== DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=17043.5fd0149f.k2012; bh=XqAENsmfTSehf7nt97YUxDrI+Otsf83SZtgy0X8H3kM=; b=DmTtDUluL38vOxJNMiTU9ExH1Px5UzVoTg97rNvL1Py/06b8xqASemf/YXh56K92s1MPyEcQ4rYAGQAFJaU887X9k6Wb2GUnmjU1XTsHj7bP1/kPlcjtjgOiRhPR14HuB94LjVBRoXc5UWqRi4/ixLB5vRq6w0UBmRDNcoc13UbfS15VSJr9nwPVVHKoG1Tx2fcpP+y+ZSjOGYIk1MTkcyybVHDjwko44vhwWJIGkyplkrMlpiW8C68CMGxX6WiOkTV5Y0lE4zh34O2gR7XuX52ETGDBZcF3L69nK0BsRLY49noa1Ztgh2lCKezlAtLZbC8dZFgFr0Y4uTsKM4g6Jg== 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; 09 Dec 2020 00:04:47 -0000 Received: by ary.qy (Postfix, from userid 501) id 205FF2938F97; Tue, 8 Dec 2020 19:04:46 -0500 (EST) Date: 8 Dec 2020 19:04:46 -0500 Message-Id: <20201209000447.205FF2938F97@ary.qy> From: "John Levine" To: dmarc@ietf.org Cc: vesely@tana.it In-Reply-To: <62b7d80e-2c39-4d02-0b5a-bd6ede7d51dc@tana.it> Organization: Taughannock Networks X-Headerized: yes Cleverness: minimal Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] Ticket #28 - Failure report mail loops X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Dec 2020 00:04:57 -0000 In article <62b7d80e-2c39-4d02-0b5a-bd6ede7d51dc@tana.it> you write: >When dmarc authentication method fails on a message, an MTA may decide to send >a failure report. If the message is itself a failure report, however, no >failure report should be sent. The question is, how does the MTA determine >whether the message is a failure report, without resorting to lengthy content >analysis? If the top level content-type is multipart/report, that would be a pretty good signal. Nonetheless I believe this is not a real problem and we should just close the ticket. Can anyone tell us about failure loops that caused an actual problem. "We sent one failure message per day every day" is not something I would call a problem. R's, John From nobody Tue Dec 8 16:52: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 4D29C3A07C8 for ; Tue, 8 Dec 2020 16:52:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.598 X-Spam-Level: X-Spam-Status: No, score=-17.598 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, RCVD_IN_DNSWL_BLOCKED=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 TMXz2gEv_dkP for ; Tue, 8 Dec 2020 16:52:10 -0800 (PST) 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 9E1CA3A0779 for ; Tue, 8 Dec 2020 16:52:10 -0800 (PST) Received: by mail-vk1-xa31.google.com with SMTP id d68so153995vka.2 for ; Tue, 08 Dec 2020 16:52:10 -0800 (PST) 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=+sDA2breHzjsCFfrBBi32osFsCYZlvYOCXjT0Jeii3g=; b=QsMz7qJd2AUeqf5bmJedB8K6Kr+0m0nsZrg5KgpelPhW+WTpvyarzp5SGBRJZ8OwwZ avT8dTUljpaPJ0aGLLlbAkW2IUcHNuoVwGxUi8mnYRsOZgRJg1RF/fdjRKRr9PUjbzdg zo445FnYr6hemfhErqwCcJlN2+08b6KoD+u9J/9897uwu9kqb+D7jNe+xFkkoy7j1bln ettlmRy0ibCLTmBn5zUQ0oC2vW1nkU33oh2ipBeOqSOvR1A2JFAi7fQPXuhnEUz+p/Yu 2mLKnkcFCeB47kjPpYHfgNpBQfVwZw1dw2ICoYAq1oGq1c81L7BMcNAR4TfBJ3A98ax5 VnXw== 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=+sDA2breHzjsCFfrBBi32osFsCYZlvYOCXjT0Jeii3g=; b=T3CDxjpgxIaG22VAqICk8XoTa9c5/E3rd4sBbtIPRotJNVlcowzNeL9qVq1N3vDH+A 532Jwx0Y26E9DNsxgMsOdatTxBLjZTmRtGR2Wp+zKy0liqCi/lewQtQkCUYSXIixfoJo ih/osAlPWdt6JaGge7XhfCKTN/H4VNDN4kcTQGRHZPEsulXtyppPp7Mc4+ruHbQu7XBu gHPXRZEkj/c/GbF+2C7OnnwZCrwEmuzbOy1+uNJ8Pt7pmczZrCWBTh7eMny0VwKdrsoL 5bC+XfuTlZPd0/80MkZO3znQR2AOKO/w3n6r14Ss3iNaHm/h35II6j7GeI4VdnEA0/To osYg== X-Gm-Message-State: AOAM5329MqxsdugwVBoesL/UjIek+jd1dOf2kPDdukBsDowO1hFusSMv FrraZQLmdfMWJfSXR33F4jIMbg5DKsdopWSHX31o X-Google-Smtp-Source: ABdhPJy01FP7plC4CB54K8fy7JjuPI1RpYN7oT8+xKqJRx/WcNtsVfbI+RGQ/WYeUot4TobFXY2mqIAupY3jGnfi3sM= X-Received: by 2002:a1f:288a:: with SMTP id o132mr19183vko.2.1607475129474; Tue, 08 Dec 2020 16:52:09 -0800 (PST) MIME-Version: 1.0 References: <20201208031609.C8CC52926414@ary.qy> In-Reply-To: From: Brandon Long Date: Tue, 8 Dec 2020 16:51:57 -0800 Message-ID: To: John R Levine Cc: "Murray S. Kucherawy" , IETF DMARC WG Content-Type: multipart/alternative; boundary="0000000000001461d105b5fd78f5" Archived-At: Subject: Re: [dmarc-ietf] A-R results for DMARC X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Dec 2020 00:52:12 -0000 --0000000000001461d105b5fd78f5 Content-Type: text/plain; charset="UTF-8" On Mon, Dec 7, 2020 at 8:31 PM John R Levine wrote: > On Mon, 7 Dec 2020, Murray S. Kucherawy wrote: > > The original intent back in RFC 5451 was to relay only those details that > > an MUA might care about, such as the DKIM result (so you can display > > something representing a "pass" or "fail" on a message) and maybe the > > domain name found in a passing signature (an early shot at caring about > > alignment when rendering a message). ... > > I suppose but 5451 also says it might be useful to message filters. > Right, there are clearly MUAs that do some amount of spam filtering, so disposition of p=quarantine would seem to be useful for that. > > So that ship has sailed, meaning yes, we could register these too if > > they're going to be useful to downstream agents. Though for that matter, > > you could just start using them even without registering them to see if > it > > would be helpful, because 8601 allows for local conventions (the > > tried-and-true "ignore what you don't know" thing that DKIM introduced). > > Sure, I can write the code to stick them in but it would be nice to have > some expectation that I'm not going to collide with something else, or > other people use different tags for the same thine. > Right, we clearly send that information around our system as separate metadata about the message... for us it would be more useful as an agreed upon place where MUAs can consume it. And it seems like in some places, disparate tools are chained together, and headers are where that metadata lives as the message flows between systems. I'm sure those places will come up with their own or add to some large X-My-System blob, but a standard place does allow different tools from different folks to be used together. Brandon --0000000000001461d105b5fd78f5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Dec 7, 2020 at 8:31 PM John R= Levine <johnl@taugh.com> wrot= e:
On Mon, 7 Dec= 2020, Murray S. Kucherawy wrote:
> The original intent back in RFC 5451 was to relay only those details t= hat
> an MUA might care about, such as the DKIM result (so you can display > something representing a "pass" or "fail" on a mes= sage) and maybe the
> domain name found in a passing signature (an early shot at caring abou= t
> alignment when rendering a message). ...

I suppose but 5451 also says it might be useful to message filters.

Right, there are clearly MUAs that do some amo= unt of spam filtering, so disposition
of p=3Dquarantine would see= m to be useful for that.
=C2=A0
> So that ship has sailed, meaning yes, we could register these too if > they're going to be useful to downstream agents.=C2=A0 Though for = that matter,
> you could just start using them even without registering them to see i= f it
> would be helpful, because 8601 allows for local conventions (the
> tried-and-true "ignore what you don't know" thing that D= KIM introduced).

Sure, I can write the code to stick them in but it would be nice to have some expectation that I'm not going to collide with something else, or =
other people use different tags for the same thine.
Right, we clearly send that information around our system as s= eparate metadata
about the message... for us it would be more use= ful as an agreed upon place
where MUAs can consume it.

And= it seems like in some places, disparate tools are chained together, and he= aders
are where that metadata lives as the message flows between = systems.=C2=A0 I'm
sure those places will come up with their = own or add to some large X-My-System blob,
but a standard place d= oes allow different tools from different folks to be used together.

Brandon=C2=A0
--0000000000001461d105b5fd78f5-- From nobody Tue Dec 8 17:45: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 9A8973A0A7E for ; Tue, 8 Dec 2020 17:45:19 -0800 (PST) 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 (2048-bit key) header.d=iecc.com header.b=GWx7H/pb; dkim=pass (2048-bit key) header.d=taugh.com header.b=GWjosmyT Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 59Nu591f3VUz for ; Tue, 8 Dec 2020 17:45:15 -0800 (PST) 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 E568E3A0A4D for ; Tue, 8 Dec 2020 17:45:13 -0800 (PST) Received: (qmail 13287 invoked from network); 9 Dec 2020 01:45:12 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type; s=33e4.5fd02c28.k2012; i=johnl-iecc.com@submit.iecc.com; bh=3AbcGBzujpzG2hRVD0Mgk6wI0yrZ2/lWCClKYD7A5cc=; b=GWx7H/pbRXPfBQJdWIvbd6LWJ6raxDJEKul4MlnOXh8v1OBA9q6oO15vJfSh2anrE/9b9eqE3N2WVGLNNGQQ75GWSFMbZ8tgQrWxXv30KS6H8QHNK8Na9M9v6BhSkFma5k7OxmicoY4DK2gpmgc9WWByNoxw6yGCBVGURlvP43cfA+OdCoNNTWmHD7pxWaQYqDcbZSOogX924BZ4XqbdcST9C0kdeA3wliSuKbXZQ4DCYgk3RpF+TmNW88lNL9jWGs5dFYUjSBbITWdfFsB8FOgqInJ7nLdrYuyDeImQDTyr6FxrARVOvJfo82GakeztW4P6TPjbjdoKj/yq7PJx5g== 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=33e4.5fd02c28.k2012; olt=johnl-iecc.com@submit.iecc.com; bh=3AbcGBzujpzG2hRVD0Mgk6wI0yrZ2/lWCClKYD7A5cc=; b=GWjosmyTTN4zhYJMl8K+zgGREWnxGYwLtUe/yEWvuvuP/53NNNmgNkEQqCquKb58OFxIf9PYn+hrjKvc5Gzio6W+gm5NKxnEzu60BGc5yjBc5HPR41XboWnYzupcfcpzFXTinPCdARcGHwpv4Q+8o4/3sD4y9k2CycCIu4YPqWZlq6FMMUSLVjRAEUOe7mWWl1KVdBU8WdGoZnxcnv//d+47725lKQEZzdNXMNs87+qrbeqgSTaKWK+Ef3qg9F8jn873L6I2YilGowR7XdHm6bnO0/Uy5g+yIVnj0JbnSw5CwpjDV/iiBSwqQuqeM7FwKhDGgZRL+U3pRB9dJYkxPw== 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; 09 Dec 2020 01:45:12 -0000 Date: 8 Dec 2020 20:45:12 -0500 Message-ID: From: "John R Levine" To: "Brandon Long" Cc: "IETF DMARC WG" In-Reply-To: References: <20201208031609.C8CC52926414@ary.qy> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [dmarc-ietf] A-R results for DMARC X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Dec 2020 01:45:20 -0000 > but a standard place does allow different tools from different folks to be > used together. Well, it was certainly easy to code: Authentication-Results: iecc.com; spf=pass spf.mailfrom=blong@google.com spf.helo=mail-vk1-xa2c.google.com smtp.remote-ip="2607:f8b0:4864:20::a2c"; dkim=pass header.d=google.com header.s=20161025 header.a=rsa-sha256 header.b="QsMz7qJd"; dmarc=pass header.from=google.com polrec.p=reject polrec.pct=100 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 Dec 8 19:37: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 E9EC23A0934 for ; Tue, 8 Dec 2020 19:37:55 -0800 (PST) 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 C1fNJA0BdveP for ; Tue, 8 Dec 2020 19:37:54 -0800 (PST) Received: from mail-ua1-x931.google.com (mail-ua1-x931.google.com [IPv6:2607:f8b0:4864:20::931]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C9F03A0930 for ; Tue, 8 Dec 2020 19:37:54 -0800 (PST) Received: by mail-ua1-x931.google.com with SMTP id w7so61674uap.13 for ; Tue, 08 Dec 2020 19:37:54 -0800 (PST) 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=AGdwVVt0v5AAKlHXGNEDesPBmBW94WLCX58YteiuFV8=; b=rn6ugtSMok4gd3umLLn7x/xB+9ICs0SihzpTqePHM2R7ga/duA5wDKYuuQ+FevfZg+ Xv2Cx0uAB2tWX/qEqaYOwcmfWaYtoiSWJ195G2p6CCc9dWkFUkdWEOcyD8vGS6/vMN4E dYDiuMYRUiAjYE629cGSux2xWKUX8aG/GppY7JBXYqq9m7a5tkT1yeoazjG/qh1TUFG/ P1Jbu6YRR5gcehLRv3YyKhcmuyttrLLOAZamCcY9451Y2zhfQzzvU1GF4SC8NevKFeAb gy5FuNwI7S24wSFEZ0K7noW1NaEGXE1r4mdoEcosaNY05o+QpBSHuUnQi6F0TG8JmyeB LJEg== 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=AGdwVVt0v5AAKlHXGNEDesPBmBW94WLCX58YteiuFV8=; b=rxi54Nn1XSXVR+VT/4pa2pBTwqtwUadrC/98kP+EYKUCsjv2uO1EgXgLoUFckK3cLK I2BCVjhVEHpv2sUjEtmF0xtn2Rp5USY1M0YAqPxYQnUppr2HG2XLHWEMRAVe7ARjpzfk HmlRd9UsxnBUV4iTfS9Ot0ZlfOsVILreDDTXQ8XSfvTGlCt0mld9amBy9Orubtr0bTGK kOSi0z07xbdt6ZkCXqor/tWkJ9Q1ztnnIT8Ow4SPCvI2oIfozhLhT+jH8ytR2bsCX2ab OyawUyM48kBpAmJWqr+T33XMfTbHUK9x0sBFKoRplErivdnu/3YVqhTEn8b+ZwwltqHF Yubw== X-Gm-Message-State: AOAM531UVw2wOt2u+f9BWM06UnBDgVv159UT6q5KsncUTbyRmbrFVmDr vvvLvhkUSE1E7krQdVp8Vrmy8V4wuPlxh+PslAUiQLAb X-Google-Smtp-Source: ABdhPJw4CtFwZLYEzy5tqroUD1T8SmubjbDHliJmybKm4UzqztyMfibdrk7Uk/+QV416KwjkPfFdm1aDWifPxoDR3g0= X-Received: by 2002:ab0:2e99:: with SMTP id f25mr231052uaa.104.1607485073006; Tue, 08 Dec 2020 19:37:53 -0800 (PST) MIME-Version: 1.0 References: <20201208031609.C8CC52926414@ary.qy> In-Reply-To: From: Douglas Foster Date: Tue, 8 Dec 2020 22:37:40 -0500 Message-ID: To: IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000c2228e05b5ffc8ce" Archived-At: Subject: Re: [dmarc-ietf] A-R results for DMARC X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Dec 2020 03:37:56 -0000 --000000000000c2228e05b5ffc8ce Content-Type: text/plain; charset="UTF-8" If included in an ARC set, John's extensions would solve my concerns about lost data during forwarding. HELO links the result to a received entry. Full SMTP address recovers data lost to SMTP rewrite. DKIM domain partially recovers from From rewrite if it is the From foaming being reported, but the full address is actually needed for some situations. On Tue, Dec 8, 2020, 8:45 PM John R Levine wrote: > > but a standard place does allow different tools from different folks to > be > > used together. > > Well, it was certainly easy to code: > > Authentication-Results: iecc.com; spf=pass spf.mailfrom=blong@google.com > spf.helo=mail-vk1-xa2c.google.com > smtp.remote-ip="2607:f8b0:4864:20::a2c"; dkim=pass header.d=google.com > header.s=20161025 header.a=rsa-sha256 header.b="QsMz7qJd"; dmarc=pass > header.from=google.com polrec.p=reject polrec.pct=100 > > Regards, > John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY > Please consider the environment before reading this e-mail. https://jl.ly > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > --000000000000c2228e05b5ffc8ce Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
If included in an ARC set, John's extensions would so= lve my concerns about lost data during forwarding.=C2=A0 =C2=A0HELO links t= he result to a received entry.=C2=A0 =C2=A0Full SMTP address recovers data = lost to SMTP rewrite.=C2=A0 DKIM domain partially recovers from From rewrit= e if it is the From foaming being reported,=C2=A0 but the full address is a= ctually needed for some situations.



On Tue, Dec 8, 2020, 8:45 PM John R Levine <johnl@taugh.com> wrote:
> but a standard place does allow different tools fro= m different folks to be
> used together.

Well, it was certainly easy to code:

=C2=A0 Authentication-Results: iecc.com; spf=3Dpass spf.mailfrom=3Dblong= @google.com spf.helo=3Dmail-vk1-xa2c.google.com s= mtp.remote-ip=3D"2607:f8b0:4864:20::a2c"; dkim=3Dpass header.d=3D= google.com header.s=3D20161025 header.a=3Drsa-sha256 header.b=3D&quo= t;QsMz7qJd"; dmarc=3Dpass header.from=3Dgoogle.com polrec.p=3Dr= eject polrec.pct=3D100

Regards,
John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

_______________________________________________
dmarc mailing list
dmar= c@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
--000000000000c2228e05b5ffc8ce-- From nobody Wed Dec 9 03:47: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 1F18A3A07A0 for ; Wed, 9 Dec 2020 03:46:59 -0800 (PST) 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 H07mtHkUGqNX for ; Wed, 9 Dec 2020 03:46:57 -0800 (PST) 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 43F013A0AF9 for ; Wed, 9 Dec 2020 03:46:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1607514401; bh=H+z9WDJ08FhpIitQsS0uqiL9O4NOxhTwv6LdnOzkMEo=; l=854; h=To:References:From:Date:In-Reply-To; b=DTJ+MXXRRa32Qvc6A06Ivc0y19G3syXCSYciI1Yhvd2CRwkyNKuVLTdknK1Jbi1CA PPHNlM5633UF2Z0auSdWq/tu+0Fff4hlEwmN7Z7bl+kFF5cXN5qc/VYU4C7xcaRsww hWhG7jrLk0Sen+L+Hr/Y3SJY4tBg8aHXWp7xy5S/3hX73Sr/uUjuYaqJYf/Jl Authentication-Results: tana.it; auth=pass (details omitted) Original-From: Alessandro Vesely 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.000000005FD0B921.0000586A; Wed, 09 Dec 2020 12:46:41 +0100 To: dmarc@ietf.org References: <20201207221345.09DD72922E4A@ary.qy> From: Alessandro Vesely Message-ID: <45879906-41f9-3af8-b4fb-64d99d552fff@tana.it> Date: Wed, 9 Dec 2020 12:46:41 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: <20201207221345.09DD72922E4A@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] Ticket #1 - SPF alignment X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 09 Dec 2020 11:46:59 -0000 On Mon 07/Dec/2020 23:13:44 +0100 John Levine wrote: > In article you write: >>> I have a slight preference for the first option. HELO is too arbitrary in >>> the protocol for me to put much value in using it in any of these systems. >> >>There's a bit of an implementation detail though. If one is relying on an >>encapsulated ck_host() function then you may not know whether it checked >>the HELO or the MAIL FROM. Imposing a requirement like this from DMARC >>seems like it verges on a layering violation. > > You should be able to look at the bounce address and if it's null, > skip the SPF check. No need to peek inside SPF for that. That would discard most bounces, since many MTAs send them directly, without going through a signing filter. Best Ale -- From nobody Wed Dec 9 06:39: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 1A0D43A16BB for ; Wed, 9 Dec 2020 06:39:55 -0800 (PST) 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 Hu0_GHqQg0nS for ; Wed, 9 Dec 2020 06:39:53 -0800 (PST) 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 8EA1A3A16B8 for ; Wed, 9 Dec 2020 06:39:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1607524790; bh=KDx18Q6DFN1rWL8JtwOZd9fP+RPSE+fYyiFFLxFwMiA=; l=463; h=To:References:From:Date:In-Reply-To; b=BrA0if74JX+Ji6KRiTOczzXiqWw7wqxnFviJLPttzSO11RzFnDaEESP84dQqHn4Nl oqomzI3jel7yYJq+mVKHlWarF27Zkma7SG8tB9O+ZPBa1Ivr1PyvrZIMqw+5oPljTw q8yRx8YWUI5tujiGGpuBT+h2hZ6eUVRp3p4VOr/HvBgPIcf/Cx52vjS/9JxeT Authentication-Results: tana.it; auth=pass (details omitted) Original-From: Alessandro Vesely 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.000000005FD0E1B6.00006DC5; Wed, 09 Dec 2020 15:39:50 +0100 To: dmarc@ietf.org References: <20201208235623.77A662938D42@ary.qy> From: Alessandro Vesely Message-ID: <5e600200-0ac7-5752-9387-eb64cbb6325b@tana.it> Date: Wed, 9 Dec 2020 15:39:50 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: <20201208235623.77A662938D42@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] Ticket #42 - Expand DMARC reporting URI functionality X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 09 Dec 2020 14:39:55 -0000 On Wed 09/Dec/2020 00:56:22 +0100 John Levine wrote: > In article you write: > > I must admit one thing that did surprise me was that something is looking at > DMARC DNS records and probing the https URIs they contain, since that is the > only place there are referecnes to my newly created https reporting URI. dmreport.abuse.net was published on the DNS. That's enough for probing. Best Ale -- From nobody Wed Dec 9 06:55: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 DC0553A0DBD for ; Wed, 9 Dec 2020 06:55:07 -0800 (PST) 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 HPoRQCMfiGAf for ; Wed, 9 Dec 2020 06:55:06 -0800 (PST) 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 BFEE53A0DA1 for ; Wed, 9 Dec 2020 06:55:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1607525704; bh=M3ThTsDvMz13pj4cLjKry8RFf0G+h63XXDh1NTSPfmY=; l=925; h=To:References:From:Date:In-Reply-To; b=A0ORqPgP6J5HhpfP/GVYS0tHZuy4Qo9cT4WwK4AoBh5iBcpgoTKtWf7MZuHF9rFlQ Tc4l/V7qQ3TGN9aywkZ/nIOVoFsHo+w4yAB0UAZhoPZDDuM3/w9GoAPBIy/eOsPyeK p7GwIC2UsP3rKi5iPRtre+Polf2E9KO5AJoZayOeFHm18uG8fGAbn+kuLJKY5 Authentication-Results: tana.it; auth=pass (details omitted) Original-From: Alessandro Vesely 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.000000005FD0E548.00006F8E; Wed, 09 Dec 2020 15:55:04 +0100 To: John Levine , dmarc@ietf.org References: <20201209000447.205FF2938F97@ary.qy> From: Alessandro Vesely Message-ID: Date: Wed, 9 Dec 2020 15:55:04 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: <20201209000447.205FF2938F97@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] Ticket #28 - Failure report mail loops X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Dec 2020 14:55:08 -0000 On Wed 09/Dec/2020 01:04:46 +0100 John Levine wrote: > In article <62b7d80e-2c39-4d02-0b5a-bd6ede7d51dc@tana.it> you write: >>When dmarc authentication method fails on a message, an MTA may decide to send >>a failure report. If the message is itself a failure report, however, no >>failure report should be sent. The question is, how does the MTA determine >>whether the message is a failure report, without resorting to lengthy content >>analysis? > > If the top level content-type is multipart/report, that would be a > pretty good signal. Works for me. It still implies no failure reports on bounces, but admins can have bounces on failure reports if they want. The change amounts to a fourth 1-liner *-bullet, for example: * never send reports for message of Content-Type: multipart/report; It seems better than the other three bullets, so I'd prepend it. Does the WG agree? Best Ale -- From nobody Wed Dec 9 07:23: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 045063A0DFB for ; Wed, 9 Dec 2020 07:23:11 -0800 (PST) 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 (2048-bit key) header.d=iecc.com header.b=pJsmvqzw; dkim=pass (2048-bit key) header.d=taugh.com header.b=gXv/jWY7 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dQQKO2ryI7K6 for ; Wed, 9 Dec 2020 07:23:09 -0800 (PST) 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 077D73A0D84 for ; Wed, 9 Dec 2020 07:23:08 -0800 (PST) Received: (qmail 60150 invoked from network); 9 Dec 2020 15:23:06 -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=eaf4.5fd0ebda.k2012; i=johnl-iecc.com@submit.iecc.com; bh=zNySHTXgoaUWbSgWjmk25MkNWBENn3lJVwEQW+TeROs=; b=pJsmvqzwhsxfsbR9+djRp6N+4XEd7b6/6gF7l2PJiAnA/WvfKTIiP3LeSau2P/quwucderHGFCiRrRyHQNq2c8u2FaJ41o0p4hdkSkIMO5nwpceHypKBhIJUyayWJchKuZ6XCqd1CPDYfkrcP21kxzUe4dRAHVlIKKowgcULsX5uzRW5gk+Ot04FOYMlu9kXA8rS65QnaQyxuP5rR8gWChRi07eYDLzM3U6/PYp/4yfAoj8uWUuL+MFnnzCbA5i03UGGQGmzAn2kFstvNAN8SYhrrxT/mYPXX9rYDntcLCV+ai3ZVVGQ3Ig6l6F/uoBqiQd8Fr3mZiS46trjvbxedA== 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=eaf4.5fd0ebda.k2012; olt=johnl-iecc.com@submit.iecc.com; bh=zNySHTXgoaUWbSgWjmk25MkNWBENn3lJVwEQW+TeROs=; b=gXv/jWY7iYA1DiVCJbaMZp1PHolms37WNX3azxGACYFa1U8GcOP1MqggqB+XArvXDAkWqYBxVcvbwivgI88u7SkiOhSGEfNBROftdFnkXoBZNTb3yPd+fDd4eO4ngQfq2tFqWFs4k0TrcW47JodfNmWZZbJgu4sotICL3Q2PdJluuEIxJO2gS6i4c74a3DgFkb9Kj119PZXxjOA7S9Wi+d3v01iQ2geL7Kdw3QscU1ik7xWt5+WBWp9dwYvZpVkNaySVOKR/M1amAwC2orP0UPkgeXxVEyYcqtpiUurj/LDW2PD5V/8hUQHsQN65W2ePr6MhpsTpiKT3zDlPfQxTBA== 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; 09 Dec 2020 15:23:05 -0000 Date: 9 Dec 2020 10:23:05 -0500 Message-ID: <6a4335a-a043-b5b5-1e36-1debae7e7a9a@taugh.com> From: "John R Levine" To: "Alessandro Vesely" , dmarc@ietf.org In-Reply-To: References: <20201209000447.205FF2938F97@ary.qy> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [dmarc-ietf] Ticket #28 - Failure report mail loops X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Dec 2020 15:23:11 -0000 On Wed, 9 Dec 2020, Alessandro Vesely wrote: > It seems better than the other three bullets, so I'd prepend it. Does the WG > agree? No. This is not a problem. There is nothing to fix. Please close this ticket. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From nobody Wed Dec 9 09:07: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 3A8043A1009 for ; Wed, 9 Dec 2020 09:07:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.12 X-Spam-Level: X-Spam-Status: No, score=-2.12 tagged_above=-999 required=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.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 CJ8-Re6pP2_K for ; Wed, 9 Dec 2020 09:07:54 -0800 (PST) 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 441613A0E63 for ; Wed, 9 Dec 2020 09:07:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1607533670; bh=gtlCgWUFld/C/wKeu0obZbn0plDRtZB12YKfCdcwXYw=; l=1750; h=To:From:Date; b=BZU0RZGgLiPxipQbJ2WXcJqsYmm3guYubV0uD0awUPGWIhf+5xeiae5Cc2NDvN+YO VrQEyjm+yhnwzxDD6XvHBVtr3dtiRq8o6yNgXEaBXK6qLKkn9a/y6YM0m5RAEACUOA ZuOpSO8ljWYHq7S+KlUxCUvv6tG+UOv/r+FKawbcWMpDrAMhhPCpNPtmRg5E7 Authentication-Results: tana.it; auth=pass (details omitted) Original-From: Alessandro Vesely 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.000000005FD10466.00007F60; Wed, 09 Dec 2020 18:07:50 +0100 To: dmarc-ietf From: Alessandro Vesely Message-ID: <609e1c9b-cc4d-d7d1-0fa8-79f515c1eee4@tana.it> Date: Wed, 9 Dec 2020 18:07:50 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [dmarc-ietf] Ticket #61 - Define and add a simplified (redacted) failure report X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 09 Dec 2020 17:07:56 -0000 We would like to close this ticket by Dec 23, two weeks from now, so please get on it. The ticket text is: It has been asked for a new report type (perhaps a subset of failure reports) that provides minimal data from the email (specifically, the initial ask is for the to: and from: email addresses only) in order to aid identification of the email's destination (and hence, the owner who can help with getting it authenticated) without providing other PII. This is a significant use case for large organizations, where the departments or other sub-organizations run their own emailing infrastructure. This has been specifically requested by multiple universities. DMARC failure reporting is based on Authentication Failure Reporting Using the Abuse Reporting Format (RFC 6591), which in turn is based on An Extensible Format for Email Feedback Reports (RFC 5965). DMARC adds five fields for the second MIME part of the report. The third part can be either the full message of just the rfc822-headers. The latter is defined in The Multipart/Report Media Type for the Reporting of Mail System Administrative Messages (RFC 6522), which mentions that Received: fields can also be useful for diagnosing failures. In any case, private data such as the local part of email addresses can be redacted according to Redaction of Potentially Sensitive Data from Mail Abuse Reports (RFC 6590). In order to be useful, reports should contain enough data to discern whether the failed message was abusive, and what stream does it belong to if it wasn't. Should DMARC Failure Reporting (our document) include some guidance about what parts of the failed message to include and which ones to redact? Best Ale -- From nobody Wed Dec 9 09:22: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 7F1113A1014 for ; Wed, 9 Dec 2020 09:22:28 -0800 (PST) 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 SRVJ-nO8XFGL for ; Wed, 9 Dec 2020 09:22:27 -0800 (PST) Received: from mail-pg1-x530.google.com (mail-pg1-x530.google.com [IPv6:2607:f8b0:4864:20::530]) (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 493FF3A10AB for ; Wed, 9 Dec 2020 09:22:07 -0800 (PST) Received: by mail-pg1-x530.google.com with SMTP id o4so1623648pgj.0 for ; Wed, 09 Dec 2020 09:22:07 -0800 (PST) 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=WEyO04ZIg/twe9zYfL2VwhoVgz5wVO84aRieGPnyII0=; b=J4AD3WaQld97EybtnARzZcG4Q6SRHh0IhoHWsDK7UDPVtQjMvmypPWEjrOd4p9k0Ph ditmeba2W2R+py8g27gOJNVlO58U5wNcX6us4a799oKkpReonEzvdfHGOZs/YJdKcgbn m+81ksdMfhf3RYOJ1cH2pGgmn7EOFmoqjLOYcJhLoHsx+O+QOH7oVCUi6WY31pIxCL4/ ef3An24q3eSC580bzFoYdhj2TSZ2/BsGGU7ZLhhw3A1bw8IFxSgyyQiiEoTF1SciBpzp D9pnWCbyGpVP60s12ThVZIZ/ZNE0VCvr95d8zg+8WD9X8aZdHIA8K2bJJmCxkxXppWvu 9bBw== 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=WEyO04ZIg/twe9zYfL2VwhoVgz5wVO84aRieGPnyII0=; b=fGvCKQL0XmXL0c2HI2xZUc1LjAMKb8DkBJ73g51NF8SnMYGRQ+qQvou+B6KW4cS+0+ Pa4JrCZAJ7vYqeEogJDAdgPimuCQASzZbdcZnJtoG0A1p01kkVXlwivi1oEmX/QSFAKe z45+xgtdV8ncjEd9KRLf3NrQuCofuKMtoG3SL5rtyPx957Pz2BZzTvVdKFfCjR4Lv+rP se0Imgu9I1v4SHbn5+AEJJ8YwpMN4g0qCYLJcjZgSHV5SpjEi+noEtWyACvyLjeoWKnG aCylRwwKye/it3rkItzgqKKQ8hESyXPGcs1tiLTnDScYDUqCr3i2DOzLzM2fdRL93tIj 8iTQ== X-Gm-Message-State: AOAM533nDViX32JTlWk+9nlsEQzVGtZup1IHQR9vMm5rLDcTYxK0YeHr mOLAmv3+FMqVW8yRocdZjseIyD/BdvE= X-Google-Smtp-Source: ABdhPJyWTjeV/N2CtXFucukrSaUtMsvhMLCxSS6diadMK5yGSBv2TBaVMPWOowGL1qoavT2rcz4q8g== X-Received: by 2002:a65:5588:: with SMTP id j8mr2813440pgs.245.1607534526406; Wed, 09 Dec 2020 09:22:06 -0800 (PST) Received: from [192.168.0.109] (c-24-130-62-181.hsd1.ca.comcast.net. [24.130.62.181]) by smtp.gmail.com with ESMTPSA id b12sm2996560pft.114.2020.12.09.09.22.05 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 09 Dec 2020 09:22:05 -0800 (PST) To: John R Levine , Alessandro Vesely , dmarc@ietf.org References: <20201209000447.205FF2938F97@ary.qy> <6a4335a-a043-b5b5-1e36-1debae7e7a9a@taugh.com> From: Dave Crocker Message-ID: <62961791-56dd-506c-b99a-098ed0ee6ca2@gmail.com> Date: Wed, 9 Dec 2020 09:22:04 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.5.1 MIME-Version: 1.0 In-Reply-To: <6a4335a-a043-b5b5-1e36-1debae7e7a9a@taugh.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] Ticket #28 - Failure report mail loops X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Dec 2020 17:22:29 -0000 On 12/9/2020 7:23 AM, John R Levine wrote: > No.  This is not a problem.  There is nothing to fix.  Please close > this ticket. +1 d/ -- Dave Crocker dcrocker@gmail.com 408.329.0791 Volunteer, Silicon Valley Chapter American Red Cross dave.crocker2@redcross.org From nobody Wed Dec 9 09:40: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 720613A1608 for ; Wed, 9 Dec 2020 09:40:38 -0800 (PST) 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 LyW9jGV_oAaX for ; Wed, 9 Dec 2020 09:40:37 -0800 (PST) Received: from mail-pg1-x533.google.com (mail-pg1-x533.google.com [IPv6:2607:f8b0:4864:20::533]) (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 06ACD3A117F for ; Wed, 9 Dec 2020 09:40:37 -0800 (PST) Received: by mail-pg1-x533.google.com with SMTP id c12so1148598pgm.4 for ; Wed, 09 Dec 2020 09:40:36 -0800 (PST) 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=YtWLtlcFJ3VvzQzrk1BjuUYNtU1ZUr581MeXNof5Qmg=; b=Mo9cmAiiSpdm8PWqPMOV+oWdYl7GFyPLImralOVVPE33ZIK6z1zxsNCQTLVOLWn3oS l9rlZpvU9aDVPPbWE8SRgFhMLPJFrjhcvS9cdehWFl9e00IStXjVcV9uO2b6CU9U4iw9 Y/Qejr1y30hLju4G82+Brn1DXizJ2KMszszXcMcDAEVQDK9CmTHG1m+1gpeUJz+SRS1p Sr0AFv44XI9j6/RtNuyjgzu2g7y5ZLFxdMfLR2i0BBwfU5a4sr2X+vsMRCxyANf03rIp 8xr9lSUo9zwjz03pBDOqT52TbAWdZPjhEE3Affrt+j1VZ8ij4OHsXhiw5fjXlBcBRMPd qDIw== 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=YtWLtlcFJ3VvzQzrk1BjuUYNtU1ZUr581MeXNof5Qmg=; b=TqZyynHdDM7iHG7P1PbGxVobJf7JdhM02AvYLB+DlkMsWB0+l/WcUDveUfks3faiqx wwRZfU6QcZQktoUPhTS5eidABZHyhDRgN4110SpnTymzCKQ7oXgppJnDMYxqBgHHDn4E qIoxBOikGXRgdedj2BjndT19rhjt7wGszfz+lpddt3FTsnaWIQ51kztO6kHhA+RtmQdj 7eIyNyFoDYp3Il/c9VN4Emj5XETGMAP4/FUJRqYCvucncntfm2vGmuCa95sarXw4HvxG /n2RRRp3ITn6799TYz9rgCrlPcb87zbcOwyfg538JHQaagkjmBDlQAcEr9XCfo01mB4j +wuQ== X-Gm-Message-State: AOAM5302IT8A3/J4jXjkJb9X2eazqVK9FJiqYjsTeMwgKNyXl3G3h8L7 iGAlIr/MnsSRIkPmuE2LsWCEFYmgCvk= X-Google-Smtp-Source: ABdhPJx7EYj3RT17YGuEjoXw++oBU6s1lGM1PbMVVx4Tb4Z3E1zqOuAOwS3bvjpyXfwdeniIZgMN9g== X-Received: by 2002:aa7:8649:0:b029:19e:16df:e5f8 with SMTP id a9-20020aa786490000b029019e16dfe5f8mr3303018pfo.41.1607535636250; Wed, 09 Dec 2020 09:40:36 -0800 (PST) Received: from [192.168.0.109] (c-24-130-62-181.hsd1.ca.comcast.net. [24.130.62.181]) by smtp.gmail.com with ESMTPSA id v6sm3356278pgk.2.2020.12.09.09.40.35 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 09 Dec 2020 09:40:35 -0800 (PST) To: Dotzero Cc: Michael Thomas , "dmarc@ietf.org" References: <9e1ce2a0-cb64-067f-dc74-aa384cf34ebd@mtcc.com> <3019b5f3-54d5-4ee1-02f4-c10201900d5a@gmail.com> From: Dave Crocker Message-ID: <923de33f-3707-facf-389e-371f6ee64008@gmail.com> Date: Wed, 9 Dec 2020 09:40:34 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------396169CA5906A1AD4882B7BE" Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] p=quarantine X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 09 Dec 2020 17:40:38 -0000 This is a multi-part message in MIME format. --------------396169CA5906A1AD4882B7BE Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 12/8/2020 12:11 PM, Dotzero wrote: > Note that I asked Two questions. Your answer appears directed to the > second question. The answer to the first question appears fairly clear > to me. Administrators of a system can restrict or delete a user > account. It really is as simple as that. So in that respect the answer > is that ultimately an individual account users do not supersede the > wishes/policy of the domain owners representatives. > > The second question is a bit more interesting, but ultimately leads > one back to the first question. As far as being long settled, I would > think that NSF AUP is an interesting precedent. > > Michael Hammer > > On Tue, Dec 8, 2020 at 2:42 PM Dave Crocker > wrote: > > On 12/8/2020 10:50 AM, Dotzero wrote: > > And here we get to some of the crucial unresolved questions > involving > > email: "Does the wishes of a user of an account at a domain > supercede > > the policies of the domain owner/administrator of a domain?" > Sorry, I misread the text I responded to.  To some extent, we all tend to be ambiguous in our references -- though the specific text I misread was not -- and it will help if we are all a lot more consistently precise. For example: Author: creates content Author Domain: controls the use of the domain, per the statement I misread.  And yes, the domain owner has ultimate authority over polices of how the domain is used, by those subject to administration by the domain owner.  Obviously the domain owner has no 'authority' over those using the domain without authorization.  For this latter set of folk, the most the domain owner can do is provide information to receivers of unauthorized use. Receivers: They have full and complete authority over their operations.  Period, full stop.  There is no 'overriding' the so-called policies of anyone with whom they do not have a pre-existing relationship. Recipients: They are, of course, subject to the policies of the owner of the platform being used.  They, to, are not subject to the desires of authors or author domain owners, except as the recipient themselves desire. Really, it will help to be boringly, redundantly precise with every reference, to leave no room for misunderstanding which actor is being referenced. d/ -- Dave Crocker dcrocker@gmail.com 408.329.0791 Volunteer, Silicon Valley Chapter American Red Cross dave.crocker2@redcross.org --------------396169CA5906A1AD4882B7BE Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 12/8/2020 12:11 PM, Dotzero wrote:
Note that I asked Two questions. Your answer appears directed to the second question. The answer to the first question appears fairly clear to me. Administrators of a system can restrict or delete a user account. It really is as simple as that. So in that respect the answer is that ultimately an individual account users do not supersede the wishes/policy of the domain owners representatives.

The second question is a bit more interesting, but ultimately leads one back to the first question. As far as being long settled, I would think that NSF AUP is an interesting precedent.

Michael Hammer

On Tue, Dec 8, 2020 at 2:42 PM Dave Crocker <dcrocker@gmail.com> wrote:
On 12/8/2020 10:50 AM, Dotzero wrote:
> And here we get to some of the crucial unresolved questions involving
> email: "Does the wishes of a user of an account at a domain supercede
> the policies of the domain owner/administrator of a domain?"


Sorry, I misread the text I responded to.  To some extent, we all tend to be ambiguous in our references -- though the specific text I misread was not -- and it will help if we are all a lot more consistently precise.


For example:

Author: creates content

Author Domain: controls the use of the domain, per the statement I misread.  And yes, the domain owner has ultimate authority over polices of how the domain is used, by those subject to administration by the domain owner.  Obviously the domain owner has no 'authority' over those using the domain without authorization.  For this latter set of folk, the most the domain owner can do is provide information to receivers of unauthorized use.

Receivers: They have full and complete authority over their operations.  Period, full stop.  There is no 'overriding' the so-called policies of anyone with whom they do not have a pre-existing relationship.

Recipients: They are, of course, subject to the policies of the owner of the platform being used.  They, to, are not subject to the desires of authors or author domain owners, except as the recipient themselves desire.


Really, it will help to be boringly, redundantly precise with every reference, to leave no room for misunderstanding which actor is being referenced.

d/

-- 
Dave Crocker
dcrocker@gmail.com
408.329.0791

Volunteer, Silicon Valley Chapter
American Red Cross
dave.crocker2@redcross.org
--------------396169CA5906A1AD4882B7BE-- From nobody Wed Dec 9 09:52: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 A2D773A165D for ; Wed, 9 Dec 2020 09:52:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.096 X-Spam-Level: X-Spam-Status: No, score=-1.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=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 Pgm90C7d24EB for ; Wed, 9 Dec 2020 09:52:29 -0800 (PST) Received: from mail-qk1-x72e.google.com (mail-qk1-x72e.google.com [IPv6:2607:f8b0:4864:20::72e]) (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 BB6D63A117F for ; Wed, 9 Dec 2020 09:52:29 -0800 (PST) Received: by mail-qk1-x72e.google.com with SMTP id n142so2058199qkn.2 for ; Wed, 09 Dec 2020 09:52:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=content-transfer-encoding:mime-version:subject:from:in-reply-to:cc :date:message-id:references:to; bh=Cn01GsjjdqyoGfACbpxBgoEOOOo1fqcWDpThrfWhbpA=; b=rscXIdUBj6k6sm3NN8jw0x1QxNbGdZkdr6aXCJazbDqllx8BBQN5RNR1EmM+YnCeZb NdT2o0NRNw8LJjVHXILwzAIca4Ks+Kh3KXI+LylanreQt1e8tvKjZSFsLpPl/O3rHph6 FpqoWAGEcq5XWIOrlRKH1zWKt7OdxlLv5PT0wMYTSGXEFA5+TtqfnT2/ZmxF0azBVYiz OoLyPIdwQKkctZ32fZYHp3YsO24uk7a85JV2K69Ysn2EGixPrbgPJY0sEzSqz6M+80s8 7PK1qq3IQKjaN7WclxRM/QrObeb/fAZ3doMibuRXS+fmfltEfI/OoCCmhJ7OQBR2jEPI TztQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:mime-version:subject :from:in-reply-to:cc:date:message-id:references:to; bh=Cn01GsjjdqyoGfACbpxBgoEOOOo1fqcWDpThrfWhbpA=; b=KykT+VNqX7mAN6t2RbHDqU469nomHDSl6sJUVJ7HJB+HlY0iPZkaRTEVMEXaWdDfNz C1gfCDCEpFoA9YwCjGI6NScZ23QJbbECHtpAiubbO3Ng9APjxYuQIZf0XDbAVJH9lRIC dZQ23m8FXTDDEB84WWfvdOcFZzInO+q1T8zrlm0Te4c+YAHiYL7P4Tay5GG510qdd1Vl reHJf/lBPf4XDcwo1tmDgcgX/wT0lyJp4IyUNPD91SnzdOICKx3NVAcU9JE5dxPgFbuj 1pOCuiq7X4s/CUfk/zECdT0dxZkocU4RzMIOYXSUyZR/D9wyovxoe5W9+DS6rOINmP1x SASQ== X-Gm-Message-State: AOAM531MF5tFBkvHtyi+lp0UecuFe3t1BPrbbzU2dyTLdHcUsMIStivq pzd27RWBpWxyRdPgRdMZRxw= X-Google-Smtp-Source: ABdhPJwUbStJO2ofHoELa4UBOINYyV0ga2PofdkcKAivvy6UUONIRo6aHVAMX6h9fshdOdAoSrgvog== X-Received: by 2002:a05:620a:15ea:: with SMTP id p10mr4443182qkm.172.1607536348728; Wed, 09 Dec 2020 09:52:28 -0800 (PST) Received: from [192.168.1.89] ([184.15.58.81]) by smtp.gmail.com with ESMTPSA id z186sm1551110qke.100.2020.12.09.09.52.28 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 09 Dec 2020 09:52:28 -0800 (PST) Content-Type: multipart/alternative; boundary=Apple-Mail-2D8F35DC-EA7B-4674-87DC-1A1EADD3F36E Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (1.0) From: tjw ietf In-Reply-To: <923de33f-3707-facf-389e-371f6ee64008@gmail.com> Cc: Dotzero , dmarc@ietf.org, Michael Thomas Date: Wed, 9 Dec 2020 12:52:27 -0500 Message-Id: <16B0B820-7080-4937-8642-3A6B84B441AA@gmail.com> References: <923de33f-3707-facf-389e-371f6ee64008@gmail.com> To: Dave Crocker X-Mailer: iPhone Mail (18B92) Archived-At: Subject: Re: [dmarc-ietf] p=quarantine X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 09 Dec 2020 17:52:32 -0000 --Apple-Mail-2D8F35DC-EA7B-4674-87DC-1A1EADD3F36E Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I agree strongly with Dave on creating boring and precise terminology/refere= nces, and they are used over and over.=20 Tim Sent from my iPhone > On Dec 9, 2020, at 12:40, Dave Crocker wrote: > =EF=BB=BF > On 12/8/2020 12:11 PM, Dotzero wrote: >> Note that I asked Two questions. Your answer appears directed to the seco= nd question. The answer to the first question appears fairly clear to me. Ad= ministrators of a system can restrict or delete a user account. It really is= as simple as that. So in that respect the answer is that ultimately an indi= vidual account users do not supersede the wishes/policy of the domain owners= representatives. >>=20 >> The second question is a bit more interesting, but ultimately leads one b= ack to the first question. As far as being long settled, I would think that N= SF AUP is an interesting precedent. >>=20 >> Michael Hammer >>=20 >> On Tue, Dec 8, 2020 at 2:42 PM Dave Crocker wrote: >>> On 12/8/2020 10:50 AM, Dotzero wrote: >>> > And here we get to some of the crucial unresolved questions involving=20= >>> > email: "Does the wishes of a user of an account at a domain supercede=20= >>> > the policies of the domain owner/administrator of a domain?" >=20 > Sorry, I misread the text I responded to. To some extent, we all tend to b= e ambiguous in our references -- though the specific text I misread was not -= - and it will help if we are all a lot more consistently precise.=20 >=20 >=20 >=20 > For example: >=20 > Author: creates content >=20 > Author Domain: controls the use of the domain, per the statement I misread= . And yes, the domain owner has ultimate authority over polices of how the d= omain is used, by those subject to administration by the domain owner. Obvi= ously the domain owner has no 'authority' over those using the domain withou= t authorization. For this latter set of folk, the most the domain owner can= do is provide information to receivers of unauthorized use. >=20 > Receivers: They have full and complete authority over their operations. P= eriod, full stop. There is no 'overriding' the so-called policies of anyone= with whom they do not have a pre-existing relationship. >=20 > Recipients: They are, of course, subject to the policies of the owner of t= he platform being used. They, to, are not subject to the desires of authors= or author domain owners, except as the recipient themselves desire. >=20 >=20 >=20 > Really, it will help to be boringly, redundantly precise with every refere= nce, to leave no room for misunderstanding which actor is being referenced. >=20 > d/ >=20 > --=20 > Dave Crocker > dcrocker@gmail.com > 408.329.0791 >=20 > Volunteer, Silicon Valley Chapter > American Red Cross > dave.crocker2@redcross.org > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc --Apple-Mail-2D8F35DC-EA7B-4674-87DC-1A1EADD3F36E Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
I agree strongl= y with Dave on creating boring and precise terminology/references, and they a= re used over and over. 



Tim

Sent from my iPhone=

On Dec 9, 2020, at 12:4= 0, Dave Crocker <dcrocker@gmail.com> wrote:

=
=EF=BB=BF =20 =20 =20
On 12/8/2020 12:11 PM, Dotzero wrote:
=
Note that I asked Two questions. Your answer appears directed to the second question. The answer to the first question appears fairly clear to me. Administrators of a system can restrict or delete a user account. It really is as simple as that. So in that respect the answer is that ultimately an individual account users do not supersede the wishes/policy of the domain owners representatives.

The second question is a bit more interesting, but ultimately leads one back to the first question. As far as being long settled, I would think that NSF AUP is an interesting precedent.

Michael Hammer

On Tue, Dec 8, 2020 at 2:42 PM= Dave Crocker <dcrocker@gmail.com> wrote:
On 12/8/2020 10:50 AM, Dotzero wrote:
> And here we get to some of the crucial unresolved questions involving
> email: "Does the wishes of a user of an account at a domain supercede
> the policies of the domain owner/administrator of a domain?"


Sorry, I misread the text I responded to.  To some extent, we al= l tend to be ambiguous in our references -- though the specific text I misread was not -- and it will help if we are all a lot more consistently precise.


For example:

Author: creates content

Author Domain: controls the use of the domain, per the statement I misread.  And yes, the domain owner has ultimate authority over= polices of how the domain is used, by those subject to administration by the domain owner.  Obviously the domain owner has no 'authority' over those using the domain without authorization.  For this latter set of folk, the most the domain owner can do is provide information to receivers of unauthorized use.

Receivers: They have full and complete authority over their operations.  Period, full stop.  There is no 'overriding' th= e so-called policies of anyone with whom they do not have a pre-existing relationship.

Recipients: They are, of course, subject to the policies of the owner of the platform being used.  They, to, are not subject to the desires of authors or author domain owners, except as the recipient themselves desire.


Really, it will help to be boringly, redundantly precise with every reference, to leave no room for misunderstanding which actor is being referenced.

d/

--=20
Dave Crocker
dcr=
ocker@gmail.com
408.329.0791

Volunteer, Silicon Valley Chapter
American Red Cross
dave.crocker2@redcross.org
=20 _______________________________________________
dmarc m= ailing list
dmarc@ietf.org
https://www.ietf.= org/mailman/listinfo/dmarc
<= /html>= --Apple-Mail-2D8F35DC-EA7B-4674-87DC-1A1EADD3F36E-- From nobody Wed Dec 9 10:09: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 3FCAC3A16DD for ; Wed, 9 Dec 2020 10:09:04 -0800 (PST) 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 hyKbm-cjvM9m for ; Wed, 9 Dec 2020 10:09:03 -0800 (PST) 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 F38113A16B3 for ; Wed, 9 Dec 2020 10:09:02 -0800 (PST) Received: by mail-pg1-x52d.google.com with SMTP id v29so1659732pgk.12 for ; Wed, 09 Dec 2020 10:09:02 -0800 (PST) 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=XkZIq8FRWQ9aIG681hCwIzux5+2mT42GUs8novG/U2M=; b=Rwi4k69vMVYaHAL+84jNMhK1BiRymbFjXBJecg0mbkyoLlOfjSfXU/gPBtFJaIJdWW jWE9+gOdtvrxzoO/ZHLf4gbV3A2c0NJFTWZm+Ixi5Eh6ss/bCcfFmn1qIc+npVJnjTJI 4cbD++gu/FTFClEotfkIQ48f8ydC6qcuCWy/u9w+JbS9P5RoUPwvam95BaR6A9FeyCEX 9HQ3b1GVlrvmESMWN6gkVi+f4xl3FR3WGATPSnnXvV2dCAD+Hbdev25GdOoFVdeaS5Di EPs6IsL07lyHY8rMSSJ7blHKLtPdxFwMmLlbvhlbvXDXU4kwOstKmDRJTWxD06r8Qhp2 n2nw== 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=XkZIq8FRWQ9aIG681hCwIzux5+2mT42GUs8novG/U2M=; b=bvDF32qyFNb78X/PMztokCcxVTzxNoe7EKWg+Fi+u1Ssen0xBO1iND03IW6reNGqYY 4J7sLvlz5pmq1j/t/OdUHAHngvMrVH8P0FX/gB8yJ9xQpgQlQ9XLCKKE6LilGPL6qZ8a hX9zQb/NHAg54pDxE6yjTAxKo41cGuJ9s2eXCx4UsLzJNJLPqLXQLni6bolIAxzRcO92 5qBD+l5ILo8vtcfmwwfHFSduHcaeFnrTqDADOzts6f5pVZQBGYoEjbDbvMw6LZSQNJa9 ipZqQuSsh4zA+wyb1l61I4b++7ytX1Z4yVgpm7QunjTV/dGPWA+VF7dGoluNMv/8W0Bm ltmw== X-Gm-Message-State: AOAM530uVSr0Gp5D31uMKYiLfkNZROH/4yG0tpF0aBkcRWjA9J8NNU2Q 2ArIo58JOuwZBH4AL4lidXIgk2jLzuI= X-Google-Smtp-Source: ABdhPJwnRoZ+qocuY1og7ghSj9NzJNOtYjjNpk8VtPaYbeyDsXMctvCFRWYo6s4Dwjjzi6N8fDbkTg== X-Received: by 2002:a62:ed15:0:b029:19d:a2c2:f9a9 with SMTP id u21-20020a62ed150000b029019da2c2f9a9mr3383848pfh.23.1607537341968; Wed, 09 Dec 2020 10:09:01 -0800 (PST) Received: from [192.168.0.109] (c-24-130-62-181.hsd1.ca.comcast.net. [24.130.62.181]) by smtp.gmail.com with ESMTPSA id p9sm3316072pfq.109.2020.12.09.10.09.01 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 09 Dec 2020 10:09:01 -0800 (PST) To: IETF DMARC WG References: <923de33f-3707-facf-389e-371f6ee64008@gmail.com> <16B0B820-7080-4937-8642-3A6B84B441AA@gmail.com> From: Dave Crocker Message-ID: Date: Wed, 9 Dec 2020 10:09:00 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.5.1 MIME-Version: 1.0 In-Reply-To: <16B0B820-7080-4937-8642-3A6B84B441AA@gmail.com> Content-Type: multipart/alternative; boundary="------------D9FDC2B6116937167A93477C" Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] p=quarantine X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 09 Dec 2020 18:09:04 -0000 This is a multi-part message in MIME format. --------------D9FDC2B6116937167A93477C Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 12/9/2020 9:52 AM, tjw ietf wrote: > Obviously the domain owner has no 'authority' over those using the > domain without authorization.  For this latter set of folk, the most > the domain owner can do is provide information to receivers of > unauthorized use. It might be worth a bit of thinking about what, exactly, DMARC can reasonably do and how it should be summarized, for popular consumption: *Alignment - *DMARC defines a basis for authenticating use of the domain name in the rfc5322.From addr-spec.  (But nothing else in that header field or elsewhere in the message, neither header nor body. *Severity of unauthorized use - *DMARC provides a means of indicating to receivers how serious the domain owner considers unauthorized use of that domain name to be. *Reporting -* DMARC defines a mechanism for reporting DMARC-related activity by a receiver I've tried to state each of these precisely and accurately, in terms of real-world pragmatics. Comments? d/ -- Dave Crocker dcrocker@gmail.com 408.329.0791 Volunteer, Silicon Valley Chapter American Red Cross dave.crocker2@redcross.org --------------D9FDC2B6116937167A93477C Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 12/9/2020 9:52 AM, tjw ietf wrote:
Obviously the domain owner has no 'authority' over those using the domain without authorization.  For this latter set of folk, the most the domain owner can do is provide information to receivers of unauthorized use.


It might be worth a bit of thinking about what, exactly, DMARC can reasonably do and how it should be summarized, for popular consumption:

Alignment - DMARC defines a basis for authenticating use of the domain name in the rfc5322.From addr-spec.  (But nothing else in that header field or elsewhere in the message, neither header nor body.

Severity of unauthorized use - DMARC provides a means of indicating to receivers how serious the domain owner considers unauthorized use of that domain name to be.

Reporting - DMARC defines a mechanism for reporting DMARC-related activity by a receiver

I've tried to state each of these precisely and accurately, in terms of real-world pragmatics.

Comments?

d/

-- 
Dave Crocker
dcrocker@gmail.com
408.329.0791

Volunteer, Silicon Valley Chapter
American Red Cross
dave.crocker2@redcross.org
--------------D9FDC2B6116937167A93477C-- From nobody Wed Dec 9 10: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 2D9983A16F7 for ; Wed, 9 Dec 2020 10:52:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.851 X-Spam-Level: X-Spam-Status: No, score=-1.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iecc.com header.b=sBmX3yVm; dkim=pass (2048-bit key) header.d=taugh.com header.b=R0X4pnPa Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WYQkRFUjQb7K for ; Wed, 9 Dec 2020 10:52:48 -0800 (PST) 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 55B4E3A16F8 for ; Wed, 9 Dec 2020 10:52:47 -0800 (PST) Received: (qmail 7954 invoked from network); 9 Dec 2020 18:52:46 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=1f10.5fd11cfe.k2012; bh=pMB8v3JmwnPz1z46E5oQTVXnflEaO9SuAejz3bi8nCU=; b=sBmX3yVmX/pVq5ekYFO37arUXkJOz4Fp+fhZbMLk0922rFCXFmTJGVcOzojajcaX44Ag/HM5Y0xGwggGtmyQcevpHLY7L16+DhF6BYzYmp0tkPr4sExtcpZUPipoNGTRFTjgd8/8mssNl1WdQ0UqxvTzK8Cn6q9bFrkLxuhDA9oHURlroXZT34QIzUDvhP6FHl/aUpCmtAK3sJm3R3TuY4pyNqPzLdsk58yRtGQsMD1p9CSdg4okZphw9sq8p3v2gDIr9hBLhszEuSQSd0ujSe2TvD2zSHDTm4rvnyqtbs7Xhdvc124tuTpk43V+Qc+r6MNwHtaHbf9DwYHo+0fTZw== DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=1f10.5fd11cfe.k2012; bh=pMB8v3JmwnPz1z46E5oQTVXnflEaO9SuAejz3bi8nCU=; b=R0X4pnPaxYViA763MSt5DfsBtcM48fyi05YIp6gNKOfm0YX+PJi4RufuGRSKGPT+vOS83yYsBY5BCDKwwSTdIZxyCOMoyN1kR3RkoPrZpVFuTBjdyrndFWFov0AAhUhPVdYCjhd/1uj7CZzhyxFIGU22eIqql+P9UEALK6pe1nWhtNDQvUPwsKMMEXTaGfPLwucC9y3Ei+Pz0PonhPQpijvVkWRgiMxUwlPf5janMDgOrYRxOOx6DQBFxRgbDANfpnqfnSNow7Bwt0BajOCEjVLtqSiTp7NeIMhkEUoFnE/di8GZfpgQw6NZPVSsmjREN4UVqQuHmEoKfTchMmY+kg== 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; 09 Dec 2020 18:52:46 -0000 Received: by ary.qy (Postfix, from userid 501) id 1D40C29474C4; Wed, 9 Dec 2020 13:52:45 -0500 (EST) Date: 9 Dec 2020 13:52:45 -0500 Message-Id: <20201209185246.1D40C29474C4@ary.qy> From: "John Levine" To: dmarc@ietf.org Cc: vesely@tana.it In-Reply-To: <609e1c9b-cc4d-d7d1-0fa8-79f515c1eee4@tana.it> Organization: Taughannock Networks X-Headerized: yes Cleverness: minimal Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] Ticket #61 - Define and add a simplified (redacted) failure report X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 09 Dec 2020 18:52:50 -0000 In article <609e1c9b-cc4d-d7d1-0fa8-79f515c1eee4@tana.it> you write: > It has been asked for a new report type (perhaps a subset of failure > reports) that provides minimal data from the email (specifically, the > initial ask is for the to: and from: email addresses only) in order to aid > identification of the email's destination (and hence, the owner who can > help with getting it authenticated) without providing other PII. As always, I would want to see some evidence of an actual problem to be solved here. In the existing format, reporters can and do redact as much as they want. Why isn't that sufficient? Looking at the actual forensic reports I get, the majority are from antispamcloud.com which gloms some report info and the failed message's headers into a text body, ignoring the spec that says it's supposed to be multipart/report. I presume if we changed the spec they still wouldn't follow it, so why bother. The rest of the reports are multipart/report, some with the whole message, some with just the headers. I think that if a reporter isn't willing to provide the headers it's unlikely to provide anything. If we have a concrete reason to believe that there are people who would send these proposed super-redacted failure reports who do not send reports now, I might consider this. Otherwise, it's not a problem and close the ticket. R's, John From nobody Wed Dec 9 13:29: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 F1ACB3A11A2 for ; Wed, 9 Dec 2020 13:29:17 -0800 (PST) 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 NQSOWXvL6VIy for ; Wed, 9 Dec 2020 13:29:16 -0800 (PST) Received: from mail-vk1-xa29.google.com (mail-vk1-xa29.google.com [IPv6:2607:f8b0:4864:20::a29]) (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 4D44A3A11B7 for ; Wed, 9 Dec 2020 13:29:16 -0800 (PST) Received: by mail-vk1-xa29.google.com with SMTP id f71so705438vka.12 for ; Wed, 09 Dec 2020 13:29:16 -0800 (PST) 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=n7P9hmztcgvoSoLJ3a94mvqGcnyfXBHy5BfYAGaFunk=; b=IFIBrTjjZu/DdTAatseDOnuV7B3cDBLAt/XoxROzNz5s8ch5z25zGLuyMbQZf7+42C +NHs7QD7u/1X8wiYZ9DhfTtAMdXQdoWFvj74XFWT1bhQFJmj52+RrBuH/Q0SGT3oaOBw TxE1/Bt+mIa37XUw6yVQY9cz6SN8g/fEBywwx75z8stDyBj5t9uCjgh16gD8QehqUbfw iN1q9OxUi4qAi7A8CC44+yw7twYYSP+ecItrKhG6f6CtGpT2BDRE4qebZowOuG7A0Z+C 5eMKXlwKexpqLO0HFIi7ev3SqfTT4mgv3ybCxPKjQmV+rpw0Gb64L5TlMTLCJ4ZiGCCu g6OQ== 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=n7P9hmztcgvoSoLJ3a94mvqGcnyfXBHy5BfYAGaFunk=; b=jIIitDvHbOVeUl3v9onXon1owJw0UWwrgAZmdTuKaC078KyRq8OoqRkNHm9NENywJx bqdl2tTmj/L5rFQhkJfCOgOloX7YllWl/AZ+lz+xu8dDiJ/jr6O0ZhcTUvvX1sPL3Qot IC5qGkEhdoa+nGg2St/hFpA12+VXuBpzBiAQhDI3+Tf+sCGveRlJSxQbB3os9sjuaoyy okTC12k7WUhYR57wECIuUQFecPlMv7Wra+zfEt1D1MTUHN/0fpBNxU21oaUT0bnSoEsp tEpoGkkVJeA4I2lrjzg5LbCV9hxOF3TRckWeNC+Nrx5lgcDmGMrajR1ILLS6Kr1xcfE/ Yh2A== X-Gm-Message-State: AOAM530EC2+2nX5GJijVorI2xVUjB7ZNNdX25ZV1Lrlr5gbMRgdE0Ysj LcBb/lT7gHJ6EjzMD5c33hROZlfcVS/cAcE/kVnxNqPyww== X-Google-Smtp-Source: ABdhPJyfyRFQFVZ/GryhKyl4hBPQWuQtWQClgFeiFcvew5EXLc3GK/paSalymyFy4T7dTFsEdmeFoJlsURxUZf3cOZ8= X-Received: by 2002:a1f:288a:: with SMTP id o132mr4487927vko.2.1607549355001; Wed, 09 Dec 2020 13:29:15 -0800 (PST) MIME-Version: 1.0 References: <609e1c9b-cc4d-d7d1-0fa8-79f515c1eee4@tana.it> <20201209185246.1D40C29474C4@ary.qy> In-Reply-To: <20201209185246.1D40C29474C4@ary.qy> From: Brandon Long Date: Wed, 9 Dec 2020 13:29:03 -0800 Message-ID: To: John Levine Cc: IETF DMARC WG , Alessandro Vesely Content-Type: multipart/alternative; boundary="00000000000043e64205b60ec01e" Archived-At: Subject: Re: [dmarc-ietf] Ticket #61 - Define and add a simplified (redacted) failure report X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 09 Dec 2020 21:29:18 -0000 --00000000000043e64205b60ec01e Content-Type: text/plain; charset="UTF-8" On Wed, Dec 9, 2020 at 10:53 AM John Levine wrote: > In article <609e1c9b-cc4d-d7d1-0fa8-79f515c1eee4@tana.it> you write: > > It has been asked for a new report type (perhaps a subset of failure > > reports) that provides minimal data from the email (specifically, the > > initial ask is for the to: and from: email addresses only) in order > to aid > > identification of the email's destination (and hence, the owner who > can > > help with getting it authenticated) without providing other PII. > > As always, I would want to see some evidence of an actual problem to > be solved here. In the existing format, reporters can and do redact as > much as they want. Why isn't that sufficient? > > Looking at the actual forensic reports I get, the majority are from > antispamcloud.com which gloms some report info and the failed > message's headers into a text body, ignoring the spec that says it's > supposed to be multipart/report. I presume if we changed the spec they > still wouldn't follow it, so why bother. > > The rest of the reports are multipart/report, some with the whole > message, some with just the headers. > > I think that if a reporter isn't willing to provide the headers it's > unlikely to provide anything. If we have a concrete reason to believe > that there are people who would send these proposed super-redacted > failure reports who do not send reports now, I might consider this. > Otherwise, it's not a problem and close the ticket. > In today's much more privacy conscious world, should we have RUF reports in DMARC at all? Brandon --00000000000043e64205b60ec01e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Dec 9, 2020 at 10:53 AM John = Levine <johnl@taugh.com> wrote= :
In article <= ;609e1c9b-cc4d-d7d1-0fa8-79f515c1eee4@tana.it> you write:
>=C2=A0 =C2=A0 =C2=A0It has been asked for a new report type (perhaps a = subset of failure
>=C2=A0 =C2=A0 =C2=A0reports) that provides minimal data from the email = (specifically, the
>=C2=A0 =C2=A0 =C2=A0initial ask is for the to: and from: email addresse= s only) in order to aid
>=C2=A0 =C2=A0 =C2=A0identification of the email's destination (and = hence, the owner who can
>=C2=A0 =C2=A0 =C2=A0help with getting it authenticated) without providi= ng other PII.

As always, I would want to see some evidence of an actual problem to
be solved here. In the existing format, reporters can and do redact as
much as they want.=C2=A0 Why isn't that sufficient?

Looking at the actual forensic reports I get, the majority are from
a= ntispamcloud.com which gloms some report info and the failed
message's headers into a text body, ignoring the spec that says it'= s
supposed to be multipart/report. I presume if we changed the spec they
still wouldn't follow it, so why bother.

The rest of the reports are multipart/report, some with the whole
message, some with just the headers.

I think that if a reporter isn't willing to provide the headers it'= s
unlikely to provide anything.=C2=A0 If we have a concrete reason to believe=
that there are people who would send these proposed super-redacted
failure reports who do not send reports now, I might consider this.
Otherwise, it's not a problem and close the ticket.

In today's much more privacy conscious world, should w= e have RUF reports in DMARC
at all?

Bran= don=C2=A0
--00000000000043e64205b60ec01e-- From nobody Wed Dec 9 13:34: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 4C0053A114C for ; Wed, 9 Dec 2020 13:34:23 -0800 (PST) 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 Hmq-mo5ZXiuy for ; Wed, 9 Dec 2020 13:34:21 -0800 (PST) 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 A4B513A10F2 for ; Wed, 9 Dec 2020 13:34:20 -0800 (PST) Received: from NAM12-BN8-obe.outbound.protection.outlook.com (mail-bn8nam12lp2172.outbound.protection.outlook.com [104.47.55.172]) by smtpauth1.wiscmail.wisc.edu (Oracle Communications Messaging Server 8.0.2.4.20190812 64bit (built Aug 12 2019)) with ESMTPS id <0QL300CTPD6K8340@smtpauth1.wiscmail.wisc.edu> for dmarc@ietf.org; Wed, 09 Dec 2020 15:32:45 -0600 (CST) 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.12.9.212417, AntiVirus-Engine: 5.79.0, AntiVirus-Data: 2020.11.17.5790001, SenderIP=[104.47.55.172] ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=crxuE+9IFZ5yeFrD31YJkymIhKXDfMx9GsGGzQbas5xq2MnGiQGvQaxCFSoE/fdTYFrakJQqD/+6ZA6XVogAtT8oZ/LWkck16c+DUYa2hB3St8lnXif/5boLX+lz0MJM72tbxIePyviRXRV4nOyqZalYV7nAMBy2JlVWcCXtu3OpGChFcz1LclVU4tFe8g7/N/8CJkBNqndGDAEhrZAuioBAruIeWzSnfmLGWdkcpGycG7/9P8jFduKwyPtYcza/g4R/nundLBBNK45oHj2rWlvbIfiqSNeYc9UmZOBvnPKGTL9JputM+pFTJa23XHXkea6SGdBYUHNZQ6eXajIKBQ== 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=e+wjVvcp3o0w2nGiW7mXIK8q3DK8X5DOV+RNRZjci3I=; b=fvaOx9Sx5o4/OJMG0oLNLSG/qpSWZIeJx+FC1UcPWcM4nBvyW/flBeQMTBRATggGRO/x0DiwmMzXIGaFabK4U/X5JnjvMoC8L7GgeEuVRMTueSND75rGlTyC/6Tszs1KnajK25aUSgqjOP5687Uo2lfb82ax9tlfFa+HWFb8hZzt4iWJirW0kNOPYQYvO4yOQ6Twfr6OABzzv7ocdpBTdYkclL8cXIkmlW6JI66lEr5u4ErsePaSBRquXBBfVNWo3tyb/Hlo+BXmLcrAK7sX9pTb/QH6RIO32twKyLa7oYdrDkHiVMQN84eRXcAoXYHze3nzgPEKK/Gi/iUlcYiz4g== 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=e+wjVvcp3o0w2nGiW7mXIK8q3DK8X5DOV+RNRZjci3I=; b=janxOWx6w+7NzPxGPilsE8rQmxne5REt9chzdNrsn6Y+Xf0doP3yDRBC6Ewye8TKrg7g+Ac8f9yCWwwN5197YNLYBk+/rAg1B16fF4ggdKvTkyV9hBTClgvQ3QUBBjO39oYkU2hF6fr4XrqaO76Rt/IZicMjtIjLT6ekU+IoMCE= Received: from PH0PR06MB7061.namprd06.prod.outlook.com (2603:10b6:510:21::8) by PH0PR06MB7622.namprd06.prod.outlook.com (2603:10b6:510:5e::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3654.12; Wed, 9 Dec 2020 21:32:44 +0000 Received: from PH0PR06MB7061.namprd06.prod.outlook.com ([fe80::51ec:c9cd:3511:1bcc]) by PH0PR06MB7061.namprd06.prod.outlook.com ([fe80::51ec:c9cd:3511:1bcc%6]) with mapi id 15.20.3632.021; Wed, 9 Dec 2020 21:32:44 +0000 To: dmarc@ietf.org References: <20201202025026.F16E128C5FDE@ary.qy> From: Jesse Thompson Message-id: Date: Wed, 9 Dec 2020 15:32:40 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 In-reply-to: <20201202025026.F16E128C5FDE@ary.qy> Content-type: text/plain; charset=utf-8 Content-language: en-US Content-transfer-encoding: 7bit X-Originating-IP: [47.12.96.133] X-ClientProxiedBy: CH2PR14CA0014.namprd14.prod.outlook.com (2603:10b6:610:60::24) To PH0PR06MB7061.namprd06.prod.outlook.com (2603:10b6:510:21::8) MIME-version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [10.0.2.111] (47.12.96.133) by CH2PR14CA0014.namprd14.prod.outlook.com (2603:10b6:610:60::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3654.12 via Frontend Transport; Wed, 9 Dec 2020 21:32:43 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: 33c9fa41-1b24-447e-78e9-08d89c89f708 X-MS-TrafficTypeDiagnostic: PH0PR06MB7622: 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: 2Rv5tlmjra6IG8lw5EZy2JMr+F3v9La+gQav8ZA9GZ9TPskxDsLrvFmiOK/kD+yaGm/nP5AGCI5mMtFKvYVrXnjIEnD0frl9jF4mUlrBDSwhfSiY0/3oSBJuouxC0YpFQ+Wm9Hj6Ke6RVRTNyDjMwar1Im5WauhKHitPw2Hki0OmvrLcB9LfV8soprlxTfzs0Y5lgyMEJmRLFXXCnNsz9Y1ezHAxcRk4rHRXMQ+FHdL9BMAL2Sy0hVXc7kMWCktab8e0/McspfipI/GLfizFGtNMZU19eUDCr/gHq8vr7bz0Gc89D4tqtDaPuoewzHV1rfp3jnGO3woK54vTOWQY81wV6VHmKKgRNM44mwqitApTOCftplPCkVFDfp+ulll7Q30pZ4WO2aRh0geRY5FXL4EWmQo/IMLxCLJnWQMttoM= X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:PH0PR06MB7061.namprd06.prod.outlook.com; PTR:; CAT:NONE; SFS:(346002)(376002)(366004)(136003)(8936002)(6916009)(86362001)(75432002)(44832011)(36756003)(5660300002)(2906002)(8676002)(508600001)(2616005)(956004)(31696002)(786003)(16576012)(83380400001)(53546011)(66556008)(6486002)(66946007)(66476007)(31686004)(186003)(16526019)(26005)(45980500001)(43740500002); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: =?utf-8?B?QXQ3UGNmZ3Z0VmQrMUVSUjlCak4rMEk4ZDA4MWM0dC9hODhydUR4RnkreGFv?= =?utf-8?B?cE91Q0tjSEQ3Vi9PbTNUOE9yeEhnaEczMzBVSnJzM1A1NFJCbU9DZzhDblF6?= =?utf-8?B?amVlNlJ3YURxNnpDMWxaTnZZb3M3d3VuMnl3RFBhYisxOWpwaERuckRjbkhx?= =?utf-8?B?M3FqYUcxS2VMbUhkUUd5VWg3NVFVUjNwMWxkc1ZsbjgzUGhoUitPUEFMcWlW?= =?utf-8?B?R1NNYTcvc1R5OTJhalgxaE5BcVAyUGhxYUJQVFRGSlhDeWV1MkZhajArbUdY?= =?utf-8?B?bEk0a3FxakhReHMweStBTHB3MEQ5V1c2K0hOaUNZdjBhRll6emROZTNuUWdo?= =?utf-8?B?cnhscCsrVTlCR3NsQUF1dG5rd05WUU1JUVZxamZDWkhVb1E3U2NKVTFjbzB4?= =?utf-8?B?YkxpMHhzdlZmMmpzNm9ZNVhncUtFRFdlT29qQTI2YzhNM3p0TU5ZeXZLVTRx?= =?utf-8?B?RmFWUGNXQWl1M3pJamhBWkp4UHROME1CZ0lUcVlMUDM4MnpYanJ0dGZYdk4y?= =?utf-8?B?cWtBWVBlZnkvNGVzamx6YVhnUWlhWmFaY1VHaHRlU1llMlVFUVNMMUZLQXIr?= =?utf-8?B?M2NySnJmT3JRU0Y1RUNyK0h6SzlrQi9tYTR4ZW9Ya0N1dmdaZHN3QUVQeXR3?= =?utf-8?B?aVdKNjRzdlJVT0QxV2p2K1RKeTNGNVU1bTZ5L2dYOTg1VHNrc2dnRFdpclF0?= =?utf-8?B?aEV0Z2VUNEs1cFNWUnByRElvWXpMaVpxZENOVWhlQ1lEZkZZcVNlSW1yUXBQ?= =?utf-8?B?TWpYbHhST0dpanZ2aW5jN0Q1Vms3emVDQThrV3ZBM1RNMzVIVkZsR0ZwVm5V?= =?utf-8?B?VWNWOGVKMDlWdlN4YTlzMUhzY0QrSEhScnZwMWxvTXZSYjhhalp0N2JIUmx3?= =?utf-8?B?djduQng4ZGV3SzdjSGppUytHWHRwYXp5c0hGQUlVMmZnTjZ0S09ObzRuZjZJ?= =?utf-8?B?allERm5LdHYrSURERS9va0FNWVgrSkRMcU9SVnRvVThRNjY4aEE4OUU1S0J2?= =?utf-8?B?cG9XSG1YbGNpZm5PUXBjemdDYXJGNSt0eUhlMzJUMzB5Q0JiSzQzOFpvdXAz?= =?utf-8?B?TmdieStnOS9LMmN4ekpQdnpBUHpMRjErRHI0TG1nZjBVVlVBemVuckRoblJT?= =?utf-8?B?eXNPKzdWQUlpZlBuSHd6UmxoSTl1ZURNbGVVZUZKcG5ZZk80Q1NMbUVJcHpL?= =?utf-8?B?WWk2ajdJcU4zQmgzYjZiWE16OHJ1bTc3MFFyMERKdXBOSlNLYndMSzUyajJi?= =?utf-8?B?NjY4K3pBYTFIOWI1TnI3R1N4akZxRmMvWW4xREMyVDA3MzNrdDBTVkpPbW5v?= =?utf-8?Q?6x9WmvEEIk9eZrS4gm/XwdoIh89jhQ2J9I?= X-OriginatorOrg: wisc.edu X-MS-Exchange-CrossTenant-AuthSource: PH0PR06MB7061.namprd06.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 Dec 2020 21:32:44.1327 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 2ca68321-0eda-4908-88b2-424a8cb4b0f9 X-MS-Exchange-CrossTenant-Network-Message-Id: 33c9fa41-1b24-447e-78e9-08d89c89f708 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: YcWa7Erq8e9Rs4pZqpJA8KCfaDCvZGaj7PjC8NYu+yOX8oPnlp6uSqBk7CuwYDtiHJJGD8XBku06szDQ/hrAEA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR06MB7622 Archived-At: Subject: Re: [dmarc-ietf] Domains and tree walk X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 09 Dec 2020 21:34:23 -0000 On 12/1/20 8:50 PM, John Levine wrote: > On the other hand, I observe that Brown, Cornell, Dartmouth, U Penn, > and Yale, whose situations are not altogether unlike Columbia's, all > publish DMARC records. Closer to home so do NYU and CUNY. They all say > p=none with rua= to collect reports. You might give them a buzz to see > how it works for them. The fact that Joseph is here raising valid deployment concerns shouldn't be overshadowed by an assumption that these other universities are ahead of the game. I participated in a hi-ed cybersecurity committee to create an "email security maturity" rubric - basically just something that CISOs can use to reflect/compare to each other. I advocated that publishing p=none and consuming the reports is a good first step, but just maturity level 1 (of 5). Some university cybersecurity organizations feel like publishing p=none (and, perhaps, not actually looking at the reports) puts them into "compliance" with this DMARC thing that only their email admins really grok. I would hesitate to assume that seeing p=none on a domain as an indicator that they are serious about deploying DMARC and reconciling their own Holy Roman Empire conundrums; rather it's there just to not be seen as lagging behind their peers, justifying funding for more SOC staff and perhaps buying some tools (*some* of which, hopefully, may be deployed to actually solve the issues identified in the DMARC reports). For better or worse, DHS BOD 18-01 mandated that all federal agencies publish p=reject on their domains. Now, *that* must have forced each agency to figure out how to actually deploy DMARC and deal with the implications. I applaud the tenacity. On 12/2/20 10:21 AM, Todd Herr wrote: > This is, I think, one of the most underappreciated features of DMARC. With p=none, a proper rua= value, and enough time, one can collect all the information needed to address any authentication shortcomings within a designated portion of the DNS namespace before moving forward to p=reject, assuming that that is one's goal with a DMARC implementation. Even for less lofty goals such as ensuring that all mail is properly DKIM signed, or that the SPF record properly enumerates all mail sources, I can't think of a better tool than DMARC aggregate reports for ferreting out that third party that the Marketing department hired to send mail on the company's behalf, or locating that one mail stream emanating from the "server" sitting at the side of Eddie the Engineer's desk. I agree with all of this. As I mentioned above, I just question the assumption that seeing p=none in a DMARC record is a good indicator that the organization is actually doing all of the things you enumerate. It's also pretty clear from my own experience that it's impossible for complex organizations to address all of their non-compliant sources of mail flow. Eventually, you just need to draw a line in the sand and cause the mail from random campus servers and ESPs who use domains without authorization to be rejected (or quarantined, in our case). On 12/2/20 1:48 PM, superuser@gmail.com wrote: > If DMARC is thus constrained and you have a "p=reject" on "columbia.edu" only, then nothing stops me from generating unauthenticated email with a From field indicating "foobar.columbia.edu" for any subdomain "foobar", whether or not it actually exists in the DNS. I also advocated that sp=reject would be a sign of a high level of maturity. I was in the minority and criticized for complicating the situation (only the flagship domain needs protection - said some). Win some battles, lose some battles. Regardless, I still feel like the tree walk is better than the org domain model since it would actually allow us to get to sp=reject. With the org domain model, we'll probably be stuck at sp=none indefinitely. Jesse From nobody Wed Dec 9 13: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 186E93A1175 for ; Wed, 9 Dec 2020 13:39:47 -0800 (PST) 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 (2048-bit key) header.d=iecc.com header.b=hTAFp/rZ; dkim=pass (2048-bit key) header.d=taugh.com header.b=D/PLHPzm Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H9kpBdWRBcwy for ; Wed, 9 Dec 2020 13:39:45 -0800 (PST) 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 E3DBC3A112D for ; Wed, 9 Dec 2020 13:39:44 -0800 (PST) Received: (qmail 45696 invoked from network); 9 Dec 2020 21:39:42 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type; s=b27e.5fd1441e.k2012; i=johnl-iecc.com@submit.iecc.com; bh=t8BI6yOl17cait51Hdc+yj/05ZuBcl6Oynyer2T5aM4=; b=hTAFp/rZSt2gY9lzCQGs98aTsS+TdP1XwSMb5xFFw9zHUWyQAB36cxyJ3F3U4oLKyBrjzkFySD+UI5MQDDlvTdXBoD1DDhPIDa+GuBtneTRunCABC5THKWsv3PGwriMP81bMzBP9RrKO4F6pw8zWZJwdsVo3pRInQstwkEsh8TeNTmf2SOtOoRU8MiEHA4/r1svihMAxVuJuWMZAcUvQZ1Ye1KRTEhStQtp10mUNr6WVSmTR4U5KDXxUxlofr1anGNslL3wCBcVZ40t6UyIN+fngPKOb/rhBmTsDNJgBUGojYlA6BWJ3DerB4vyOlgtzIxTdyaFBQA9CBhXQpNXLfw== 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=b27e.5fd1441e.k2012; olt=johnl-iecc.com@submit.iecc.com; bh=t8BI6yOl17cait51Hdc+yj/05ZuBcl6Oynyer2T5aM4=; b=D/PLHPzmuS3DQnwErEBza8AJ2kpyl1c+Bw6vFOBzL5trWjKBZDkpOhJPNSwBILV80L5Q2H0bLm4qzc6FIC0GI1BR9Yb0gHVxqk4hZVpdojM2Wp9GK8cpa6W4oawMWbzJIb3d7EU9ch1EsfF8dgoJm0bFGtlW6B+mcIfp/M9fzIeKO6YEMKLRmWWVlVCGwThi4KzChGBoMXb1H3HY8l9koCH+XaMGLOcOAjp9nCl0GFA6gN4TV2sOi5xEoR+DpiUXssjSXuoqDGusVvlzi3aASYc1Ha/jQkNa41ITYTP1RrIxz+s34PD6UFaRpXUHYSpZ6zkdPz8a6vaux66WSb1LmQ== 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; 09 Dec 2020 21:39:41 -0000 Date: 9 Dec 2020 16:39:41 -0500 Message-ID: <13972f3-7815-62ad-63ab-a349cee658e1@taugh.com> From: "John R Levine" To: "Brandon Long" Cc: "IETF DMARC WG" In-Reply-To: References: <609e1c9b-cc4d-d7d1-0fa8-79f515c1eee4@tana.it> <20201209185246.1D40C29474C4@ary.qy> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [dmarc-ietf] Ticket #61 - Define and add a simplified (redacted) failure report X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 09 Dec 2020 21:39:47 -0000 yOn Wed, 9 Dec 2020, Brandon Long wrote: >> I think that if a reporter isn't willing to provide the headers it's >> unlikely to provide anything. > In today's much more privacy conscious world, should we have RUF reports in > DMARC at all? It's a reasonable question, but a company in Redmond WA is sending me unredacted reports every daay so presumably someone thinks they are OK. I agree they're a lot less popular than aggregate reports, and don't see any reason to spend more time on them. That's why I didn't propose an http version of ruf reports. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From nobody Wed Dec 9 14: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 E3D193A173D for ; Wed, 9 Dec 2020 14:27:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, 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=mtcc.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 d3pcuRHFTWQL for ; Wed, 9 Dec 2020 14:27:05 -0800 (PST) Received: from mail-pl1-x62e.google.com (mail-pl1-x62e.google.com [IPv6:2607:f8b0:4864:20::62e]) (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 BB6323A173E for ; Wed, 9 Dec 2020 14:27:05 -0800 (PST) Received: by mail-pl1-x62e.google.com with SMTP id j1so1729379pld.3 for ; Wed, 09 Dec 2020 14:27:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mtcc.com; s=fluffulence; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=TWvWnU4dqhTOkRbPS4TgPaTuahcg/nPGa4U2A+ziFzY=; b=aY7HZDkwdiewPop8uCL3NtNUcNHycvVn2PkoyxVo8Fe3F2Uy3Kdy2qr7ZyaCBo56yB E7xIYhla2BvYR3RIxtODoYOqREg2LRBLYgksC/Lh5Txuxh/F/NWkjrbeqYeSDvuYZR6a lAO+BvvJtlCXqaoUUQM/a/WGkdwB2neoCffqP2oz72rAAF22OYlkaQhU2SkZ9WUXNtR0 mejkJHaFDBBO+rl0lG0rtLR32IdnyCIlEnZtHhHCPgSeIArEeTXk3OlsiZJZSPesyXOK grdWlEM6DZejpan0MxE8NrWM3PJbNZxaxw14xzDW7gv46fBTfVYY3UdS+33Deb5Uu/6V /Ldg== 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=TWvWnU4dqhTOkRbPS4TgPaTuahcg/nPGa4U2A+ziFzY=; b=KVgFM3kPoRQqbPZbsgbD19ELLA5tNRsgNu6MeNd9NVplyET/VtBrDFag7I5zsBtpxt oPEK2cvoJbwOIcDsOI5ZP8c8Qf3xTAoZ4UiA21u1wS2W+Gp8nPxHWSy2NqIPl/XXb8LC E9nF2FGx63jAFPVuVXz/Uz61vMvSeVSR7qeU483fQEH2nHcyqICDndZmeAXguS3bwD8D 7teTHZK2TSBBcCzFycorP40w+pTYHy5/JSiZRo/LlyGrChoFO4iXB4z3m9QmiLU4YF1v HBEEiLMo652jHJwb72+uXAY1R1K+KACkMy4//D4Do9uVjtblVk/q1fgQIZDzXnZsxej7 WKlA== X-Gm-Message-State: AOAM5316FU7cy1XYZpIKHpvtuIQ7Dzh+M5hWBl9vHtWCfcI9W8Pna9P2 gFamC/QAYEzPxPYNRGZWalykC3Qz7LXCWQ== X-Google-Smtp-Source: ABdhPJyap7W/XJYyr64I38fnMD5cG/uuwk/19v2CiWKrkTKbVoOTfMTFsd0h8dzquQA4RKhm0PqHRA== X-Received: by 2002:a17:902:a415:b029:d8:f55b:5e9b with SMTP id p21-20020a170902a415b02900d8f55b5e9bmr3876897plq.6.1607552824622; Wed, 09 Dec 2020 14:27:04 -0800 (PST) Received: from mike-mac.lan (107-182-41-154.volcanocom.com. [107.182.41.154]) by smtp.gmail.com with ESMTPSA id ck20sm3253707pjb.20.2020.12.09.14.27.02 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 09 Dec 2020 14:27:03 -0800 (PST) To: dmarc@ietf.org References: <20201208031609.C8CC52926414@ary.qy> From: Michael Thomas Message-ID: Date: Wed, 9 Dec 2020 14:27:01 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------F48E23239BB8415D4F3E9095" Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] A-R results for DMARC X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Dec 2020 22:27:07 -0000 This is a multi-part message in MIME format. --------------F48E23239BB8415D4F3E9095 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 12/8/20 4:51 PM, Brandon Long wrote: > > > On Mon, Dec 7, 2020 at 8:31 PM John R Levine > wrote: > > On Mon, 7 Dec 2020, Murray S. Kucherawy wrote: > > The original intent back in RFC 5451 was to relay only those > details that > > an MUA might care about, such as the DKIM result (so you can display > > something representing a "pass" or "fail" on a message) and > maybe the > > domain name found in a passing signature (an early shot at > caring about > > alignment when rendering a message). ... > > I suppose but 5451 also says it might be useful to message filters. > > > Right, there are clearly MUAs that do some amount of spam filtering, > so disposition > of p=quarantine would seem to be useful for that. Is there any evidence for that though? I would assume that the folks on this list use a diverse set of MUA's and would be in a position to tell us if some of them do. I'm guessing by your statement that gmail doesn't do anything different. Mike --------------F48E23239BB8415D4F3E9095 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit


On 12/8/20 4:51 PM, Brandon Long wrote:


On Mon, Dec 7, 2020 at 8:31 PM John R Levine <johnl@taugh.com> wrote:
On Mon, 7 Dec 2020, Murray S. Kucherawy wrote:
> The original intent back in RFC 5451 was to relay only those details that
> an MUA might care about, such as the DKIM result (so you can display
> something representing a "pass" or "fail" on a message) and maybe the
> domain name found in a passing signature (an early shot at caring about
> alignment when rendering a message). ...

I suppose but 5451 also says it might be useful to message filters.

Right, there are clearly MUAs that do some amount of spam filtering, so disposition
of p=quarantine would seem to be useful for that.

Is there any evidence for that though? I would assume that the folks on this list use a diverse set of MUA's and would be in a position to tell us if some of them do. I'm guessing by your statement that gmail doesn't do anything different.

Mike
--------------F48E23239BB8415D4F3E9095-- From nobody Wed Dec 9 14:37: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 6E90F3A1784 for ; Wed, 9 Dec 2020 14:37:55 -0800 (PST) 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 QYQuoTYq9ssm for ; Wed, 9 Dec 2020 14:37:53 -0800 (PST) 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 BFD9C3A1782 for ; Wed, 9 Dec 2020 14:37:53 -0800 (PST) Received: from NAM10-BN7-obe.outbound.protection.outlook.com (mail-bn7nam10lp2106.outbound.protection.outlook.com [104.47.70.106]) by smtpauth4.wiscmail.wisc.edu (Oracle Communications Messaging Server 8.0.2.4.20190812 64bit (built Aug 12 2019)) with ESMTPS id <0QL30376PFUMV7A0@smtpauth4.wiscmail.wisc.edu> for dmarc@ietf.org; Wed, 09 Dec 2020 16:30:23 -0600 (CST) 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.12.9.222717, AntiVirus-Engine: 5.79.0, AntiVirus-Data: 2020.11.19.5790001, SenderIP=[104.47.70.106] ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Norr3KCs1HCaCOJ6aK1l+cd6oe47jGSVYvxzR2hnEgjcfJaPLPFRNP7110GcfrOkEN8yOzOJTsA6PS3nKtToCSJKIvlLqTbmdR3ySQQCLf/z8r7i+GtHfW4dye/2SlSs0COpcCDJQzlneqOUfCYO4v6gWN8cM+DvxUFzeBqh5x7qTddb6FO/lB79ugQSy82q9QxYWF5O9GuBn5GebkR1GoNT0FeujR6LxfPFy3y8GDFlKJE5VCXmax/hIf95nSYgFey6P4L0BYhaz2H3pI0OtWjFBU+eulpjSQia2aaB8uGEpQitJFDczr3zMQLfxunxlAqG0NmQfDnx/kXllyz/pQ== 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=u2t18IqD9JCXvzl/tmg/Ry15vuKNtmKfFvRbi8Cugsk=; b=TR5yntnTjLx16GM80sf6hd8M0VOfHAm3KH3jbKYj+Y8CQesYtaQrtc5Ngii25jyRSMaOXTQQy8SW4JPquwWNIRrY9wiRT8wtIAjXcrY2lWtVjLv0CwE1koXy4ZD2os1LoycCvFF5lXXA7q4jMe6QbIpmK4pYDeIq0u77aFvsAtJyHBi4ZoBnJjPzNtWeQL2k8c9o2v6J4Zi8z8tFzc66uLAfuXuI4+fovN0Aze+4f5+HBm8Artq7J/sE+YaFwqPyvDdUK+wk44hZMaaZ1SeE0zSx1leehnYUbK09ACagLiq9t7kEm5cLL1SppsibD5I/J/oIrdLEowbR9eD8+kRzWA== 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=u2t18IqD9JCXvzl/tmg/Ry15vuKNtmKfFvRbi8Cugsk=; b=pCRqoV6VBJ6RuZWvd8jtUcWTQNU66UAaQb3xxV9QxS8G+MDzfRkwgcalIhULUuU/XMcXY0wRG1hyPXOOfUs0+Zgjbv9JCtHv6lp0tv7rEam3aOpvHPmCYPbFVB2I/kDkE8x4aekVnmRG01zzhEaYApByHrGwMD+MNYpg0y7Nvyo= Received: from PH0PR06MB7061.namprd06.prod.outlook.com (2603:10b6:510:21::8) by PH0PR06MB7031.namprd06.prod.outlook.com (2603:10b6:510:26::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3654.12; Wed, 9 Dec 2020 22:30:22 +0000 Received: from PH0PR06MB7061.namprd06.prod.outlook.com ([fe80::51ec:c9cd:3511:1bcc]) by PH0PR06MB7061.namprd06.prod.outlook.com ([fe80::51ec:c9cd:3511:1bcc%6]) with mapi id 15.20.3632.021; Wed, 9 Dec 2020 22:30:21 +0000 To: dmarc@ietf.org References: <5C559553-3F45-494D-9714-F7BC47BB82FF@wordtothewise.com> <2F1BED43-5AE5-42BC-AA45-67C5FDAF6CB8@wordtothewise.com> From: Jesse Thompson Message-id: <44dcdc6e-439b-36af-22ee-c2b6fc40ff59@wisc.edu> Date: Wed, 9 Dec 2020 16:30:19 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 In-reply-to: Content-type: text/plain; charset=utf-8 Content-language: en-US Content-transfer-encoding: 8bit X-Originating-IP: [47.12.96.133] X-ClientProxiedBy: CH2PR08CA0002.namprd08.prod.outlook.com (2603:10b6:610:5a::12) To PH0PR06MB7061.namprd06.prod.outlook.com (2603:10b6:510:21::8) MIME-version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [10.0.2.111] (47.12.96.133) by CH2PR08CA0002.namprd08.prod.outlook.com (2603:10b6:610:5a::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3654.12 via Frontend Transport; Wed, 9 Dec 2020 22:30:21 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: f21847c1-470b-463e-039c-08d89c92040c X-MS-TrafficTypeDiagnostic: PH0PR06MB7031: 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: Obd5NEsdqWZcOGiy5u/MpU8MgKaJmxRpVm2T2fRIg52MEC/sL2zqJzwe/Udkhe/9vYXSzC/NKsr+22v8uPwUUi1U6TIaQ7i27DnBrwjRadEAqGpjVvPhg0XDa6UxfeJAxIJ1LfFjWBNXUsOGlilww4mLGrSCV4xyJdnnP6TqHhQG24xTSEofSsnVlX8MKvRbCwIax1GCGDsJKl8orWFSZ3F31lN94tcrM/nbUv/KLnQSFWMOHd41hxE31maJFqXJdXuKK1e/D3AnZVnbl7/GkW4NovIwgGHqQQVR0pval44+UAkLG928CvDLattHkzsILaMRIdHpB9vp6jIGL1aqI29nv/LlGOpn9DMiRBM3d30qVA69NG5BzH7EfwOx8XJXCFS7BKycH9cNncso2YXd8l5akpYmS6QVAmFM3ePPTH0= X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:PH0PR06MB7061.namprd06.prod.outlook.com; PTR:; CAT:NONE; SFS:(136003)(346002)(376002)(366004)(956004)(44832011)(508600001)(786003)(86362001)(75432002)(36756003)(31686004)(16576012)(16526019)(6916009)(53546011)(2616005)(26005)(6486002)(186003)(31696002)(66946007)(8936002)(2906002)(66556008)(83380400001)(66476007)(8676002)(5660300002)(45980500001)(43740500002); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: =?utf-8?B?Z0R1UENmVXluTGhZd0gvMTB5eHNEa0JmSUJlWTBqRFdoaTl6bDdTZEFRSkFy?= =?utf-8?B?eURjSWNCNTA1Y05aazJpNTAwK3ExZ1I4ejNuV1JjdEVsZFk0cmszUk54L2Rx?= =?utf-8?B?OWt0Y0RiMnJ6R2VhaFRGR1A3RXlsSnhhWGd6ZHBManNPYk1ZdTQzRVQrOE54?= =?utf-8?B?WFhTNWp5OGVMSVlPdVhLN0J1OUVpbXJxWHZEajFYcTlYRUkvUEhjUUx6blZo?= =?utf-8?B?eFNKbU1kWU5BMmxKYk0veHNUNFlYVkt2TUxPQTNKd05xQk5vSDhucXlGRGhM?= =?utf-8?B?RkxYdnhjUVFreWNEanhkVWZEdkp2L3BIcDJidmhaV3ZGMVlzZk9WOXJ1R1VQ?= =?utf-8?B?TlhmUXdzWkh0bjVxQWV0VGpGNXE0TTdxZ0JmakJZQTBBV2s5T0V3YnVIUVJ3?= =?utf-8?B?Q0dTVWkvUWl6ekIvdUpjUEFEZEs1M1NwZE5yRkJySDY0UGJTTCtlNDVlYzA1?= =?utf-8?B?MHRWT0dXY3dNWFo3eUl3aUdIMk80NTV6U0UxaGpQSUZuc1dxM0RsejFTSDRE?= =?utf-8?B?NkZWUHQzS3o0K3NJdUp5UE5CY1c2VE1FUC9KSmhvYkJWeXdsbTd0TnBkVCtW?= =?utf-8?B?c1dpWkV6Mnl3elp0NmFONUlrRHhiUzVHV21ZV0tjM09pdVhMS0VaV3dtcHc0?= =?utf-8?B?OHhHY2g4aXpnRFZVV0pySnAzMk5IZE9UcjI5L0hqUlhRM1lTbDEwRkszNzNN?= =?utf-8?B?bkFqa2hDYnVGMWovWFlUVzBsVi9iQjBnVVlzazJ1dDEwYUpta2gzaTVEWUVP?= =?utf-8?B?N2xZd2R1MURKY1VjNTdvY2ZsUnd5NkZadU9oOHI3Ny9NVnkyWDBndE4veVd5?= =?utf-8?B?aS9WUnhMVm5GUjhWR2FNUzZwVW12a1lvN29hZFFkeHdYa3F1d1pBdit5RmQz?= =?utf-8?B?T2xSVUZwbXlBM3pvcjc3Mk9LTkw4RjNqYVFIZ1kzMWxNUkh6czVEaEozaDly?= =?utf-8?B?bmRzV0F0QndwNGg1T2FyeTZsejBmVUx5TEZ6RkdGTnN5ZHRsa2pVVUtLYklI?= =?utf-8?B?N0IxR0ZSaS9Scms2dVZVZU5VaitTU3hScGNKZ3RqbStad0dWdjArb011dVRz?= =?utf-8?B?SFo4UjVOWlVWWmN4eGl1ZkJ4WlBRaUJldzZ4RmtyaFdXMGVQd3NFdjZoOUxS?= =?utf-8?B?ajVRY0F2bStwUHA2bVBpa3o5bUZ1UlRXS0FyTk1ZZHlLeHVCTjFNcmtxR0dR?= =?utf-8?B?bkQvN3hHUVRTeXRrYzB0NkN4d2VXMlUvTnlHK2llQysxNjgwSVNNQk5WY0JK?= =?utf-8?B?eGZxWXpha1NMMFcwcVZPZzhoY1pvZElqSGc2OTBreGhxeUdGdEY4djg1MDRs?= =?utf-8?Q?tHkL1Q1SLiQRMIcRQtggowooL/Gb1K/1ju?= X-OriginatorOrg: wisc.edu X-MS-Exchange-CrossTenant-AuthSource: PH0PR06MB7061.namprd06.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 Dec 2020 22:30:21.8864 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 2ca68321-0eda-4908-88b2-424a8cb4b0f9 X-MS-Exchange-CrossTenant-Network-Message-Id: f21847c1-470b-463e-039c-08d89c92040c X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: 8gOm7WFw8W/1Dx47GS0B7kXs1e0z6HzXh3jcg8PjUjsLp69z+OwliQbVdh1E2ZL5xnEbRN4aj46fz6scgGSFBw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR06MB7031 Archived-At: Subject: Re: [dmarc-ietf] Ticket #39 - remove p=quarantine X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 09 Dec 2020 22:37:55 -0000 On 12/3/20 8:21 AM, Todd Herr wrote: > On Thu, Dec 3, 2020 at 4:28 AM Laura Atkins > wrote: > > > >> On 3 Dec 2020, at 06:03, Jim Fenton > wrote: >> >> On 2 Dec 2020, at 1:47, Laura Atkins wrote: >> >>> p=quarantine is quite useful, particularly for those folks who are trying to get to a p=reject state. >>> >>> In practice, senders who publish p=none don’t find all of the indirect mail flows as some mailing lists do nothing to transform the 5322.from address for a p=none policy. Senders have found that when they switch from p=none to p=quarantine pct=0 they regularly find mail that was not failing for a p=none. >> >> I’m really confused by this. It sounds like the 5322.from address rewriting is creating additional errors that didn’t exist beforehand, and that’s the opposite of the intended purpose. Isn’t the purpose of rewriting the 5322.from address to change the domain to that of the mediator, which should redirect reporting to the mediator rather than the original sender? > > What I am trying to say is that as I understand it from the folks who professionally deploy DMARC, they regularly use p=quarantine pct=0 as part of the deployment process. There are DMARC failures that go undetected in a p=none situation but that is detected in a p=quarantine  pct=0 situation.  My understanding was this was related to indirect flows through mailing lists and how mailing lists are handling the header transformation but it’s possible I got that piece incorrect.  > > > Time was (and may still be) that there was a very specific type of mailing list for which p=quarantine, pct=0 was required to get accurate DMARC reporting, and that was for mail that transited Google groups. There've been a couple of public discussions of the topic over on mailop, including a thread from April 2018 with the subject of "DMARC p=quarantine pct=0".  p=quarantine pct=0 is a very useful strategy 1) It allowed us to find the mailing lists that don't munge from the From header - which would subsequently be problematic once we moved to pct=100 2) It allowed us to segregate the user complaints. With a large change initiative you need to reduce the number of uncontrolled variables at any one time. If we went straight to pct=100 then there would be a mix of people complaining about from munging mixed in with complaints about delivery. Confusion would ensue and the entire premise of DMARC would have been called into question. By using an incremental process it's easier to deflect people complaining about the Stage 1 problems after moving to Stage 2. 3) It allowed us to discover email receivers who ignore pct. It was annoying, but also a convenient gift in disguise, since it allowed us to innocently blame the receiver when non-compliant senders objected to the necessary DMARC adaptations. Jesse From nobody Wed Dec 9 15:05: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 08D043A17E8 for ; Wed, 9 Dec 2020 15:05:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, 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=mtcc.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 eOeuVFWIrOMU for ; Wed, 9 Dec 2020 15:05:56 -0800 (PST) Received: from mail-pg1-x530.google.com (mail-pg1-x530.google.com [IPv6:2607:f8b0:4864:20::530]) (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 146363A17E9 for ; Wed, 9 Dec 2020 15:05:56 -0800 (PST) Received: by mail-pg1-x530.google.com with SMTP id n7so2360870pgg.2 for ; Wed, 09 Dec 2020 15:05:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mtcc.com; s=fluffulence; h=to:from:subject:message-id:date:user-agent:mime-version :content-transfer-encoding:content-language; bh=qykRQ91ZXp4/vTuZwzyy2j6zpFsDjVtIRgdXSWd6sM0=; b=QndP671WjhcGgfi5nWHOFDnIuiyl7/zIwDAJ8t9EYa6rvFbdklVQ3x7qxK5KT3hmvS VUSJG5y+AL7O7eyt5kPIfAHUWCqzwO67V9B9d0/NCb+J3GoVTvgdIT30HoelH+b+Tlq9 DHYI5Mnarki4cC1UBGv1vLy38fHhZYi8Nvog8kSSWQbIIirJo3qtJE89YmaKqsEx1VOC djaunb8XTe6QIpypslsFLLaeg4JR3vB4LSBwEDC/YZf6CLVgyG4jR0V4HCyenXsuCEDe hNZORQao1Uxk1Qt531zvniAmd2zM/4jN4mFXtjs1AsT5MPkpZmchSElRHvwPdZt3ZwRr kDvw== 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-transfer-encoding:content-language; bh=qykRQ91ZXp4/vTuZwzyy2j6zpFsDjVtIRgdXSWd6sM0=; b=LAy5Gxq1bClUg4LiH15rEC3cxwXtFE8vBRWJPXlfU/unGLS2fPeIyubm9genE3xyWk X5DpEFgbz4z7ceLiUXspWgszLb2myD3e2jQnr7vzr9FImU+d5qnsoURrWt/n5/9h7Flo Vlz9uJ9Zc/KHfZYEnLjZiss/x3SdUuFmkEoF0+T9PY89ZadQ4wIS33GkfOuFj5ySbizE ptQDa9WTTt1EVyNAcDROUEiPD2x5fXaiNaTXwoQ/7+iCs5wGkE6hIZrke7d4Y+3/VEOL ctZxf92nrlOaGDP54uHURMGvqbE+0WTtRZet8iiDwuguCQGfDO4Nm4ssxQnbbApo8IBm Hwtw== X-Gm-Message-State: AOAM530/qV2BNH/S8kO05w22D4Fq4hOhULSfSBYVR1V+PMCXivLxOXtt RSaT/aH2As/h38xtM10E0lkCqjXNnhxjOA== X-Google-Smtp-Source: ABdhPJw9+EzuITsuAMCh+aGE5SYypQCC6W+2u5GIeEM8DBoYIiqZwb8DOCYt2cxA8srJqcshBc3aUQ== X-Received: by 2002:aa7:8a88:0:b029:19d:8f05:b7a6 with SMTP id a8-20020aa78a880000b029019d8f05b7a6mr4255476pfc.39.1607555155167; Wed, 09 Dec 2020 15:05:55 -0800 (PST) Received: from mike-mac.lan (107-182-41-154.volcanocom.com. [107.182.41.154]) by smtp.gmail.com with ESMTPSA id d1sm3643388pfh.138.2020.12.09.15.05.53 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 09 Dec 2020 15:05:54 -0800 (PST) To: "dmarc@ietf.org" From: Michael Thomas Message-ID: Date: Wed, 9 Dec 2020 15:05:52 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: [dmarc-ietf] are mailing lists worth saving? X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 09 Dec 2020 23:05:57 -0000 I know it's heresy on an ietf list to suggest it, but we know that amount of traffic going through mailing lists is tiny -- like a couple percent. The amount of traffic going through other forms of manglers has to be even farther down in the long tail of traffic. Mailing lists arose because that's pretty much the only way you could get one to many communication (ignoring usenet). But with the rise of the web that ceased being true, and a lot of that traffic is now just web-based forums, etc. The benefit for DMARC, of course, is that we could just pick the few nits left in the spec and call it a day knowing that p=reject is perfectly fine in a mailing-list-as-historic world. IETF has always been pretty retrograde and conservative -- I mean, a thousand long thread of hand wringing about FTP fergawdsake on the ietf list shows that. But mailing lists are seriously ancient technology and maybe they like FTP have outlived their usefulness for all of the trouble they cause. Would it even take all that much effort? Mailing lists could easily be gatewayed to something that sinks the messages and provides a UI to read  them if your home domain is set up as p=reject. For all I know, such services already exist. Something with its own UI could even create the UI such that it even preserves the DKIM signature! No need to modify things in-band. Basically just declare that mailing lists do not meet the security requirements of the modern internet and they are an intractable problem without a good solution... just like FTP. Mike From nobody Wed Dec 9 15:37: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 483643A0408 for ; Wed, 9 Dec 2020 15:37:34 -0800 (PST) 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 Q1KC6vwRvIHZ for ; Wed, 9 Dec 2020 15:37:32 -0800 (PST) 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 A41843A03F3 for ; Wed, 9 Dec 2020 15:37:32 -0800 (PST) Received: by mail-ua1-x930.google.com with SMTP id y21so1107825uag.2 for ; Wed, 09 Dec 2020 15:37:32 -0800 (PST) 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=pLt2q0lwcDSpRrLb3jgfRY12khuaM5wr6ATs5ch+ikc=; b=vSvHhmY58Eei8IQ52wgH8+/tTbaFrSklvObFjJZSavtegHbeXNNp+/707o1kq+tpMK ElG5Ko8Den8oZIi03pZpQl9cD5fpAGBMqsa7No/9GXWhlawxYI/mCosIN59BxhEByG0n rqr+cHL+J6pVHLd1/a2SKBKntMsvNMsNsQBSBft/pshPaNUPtFeM7UGLwIPXCxQuo4w5 18VOV4KMFvSAOWQQQynNiqglMRzBp/9M3OpDagPbeerQnK1RhW0nXWypsDrChV7meQbN d94RIaNJKfAcVYQT4Bn57bkoqEILjvsHnivFWVtvwGvfimVKrBqWfwWA4haNTsgcstwB IhUQ== 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=pLt2q0lwcDSpRrLb3jgfRY12khuaM5wr6ATs5ch+ikc=; b=DqagxhfHmbjYsvC7QlrmGM7tcYlZxNdTIjuPjAF60qI3yNzpgp3a+vEIB9at7meAxI Q+T/1nihcV/iV3qvDqcogcOLWihcucWjL9RRb2lW+ol5SZsenxAlFXpZX3eqOlUnj1fD oOCU6G4QLaMBSybsmw5eyRwGOjzXLZdfgsX4z5UPD8oXK0WeCQTqHHbpFtY/pRMLPGEB aAxlca4H2ixs79gAvbZIrOrTM12cYqCqsqbTpVXasOhsC58fDPIya2Jb+st7+HVPdoNz GFHhSI5O+3/QsRXwEDijA6OkkrGYq0O1e4LMwHrZLCX+FjTOx8qBHLm5TC3zwpgvO3tn R4/Q== X-Gm-Message-State: AOAM530wIhvPf2DQC4l/TyrutZXYV6SMmACahTajFnLMWdmp9zwx1RlL /pjJrxJMFAabqtwCUaMlbNJ6Z1HKjlto3m7/0QAMHheGyGAj X-Google-Smtp-Source: ABdhPJzJTWXX6dmDL4Iev19ek68mF4EZeX6DxKTI5ENqyIqpmRaOZalYzRB4OuyKEzCLidh8snziZmhEVdBaTNjSyBU= X-Received: by 2002:ab0:486:: with SMTP id 6mr4587699uaw.6.1607557051107; Wed, 09 Dec 2020 15:37:31 -0800 (PST) MIME-Version: 1.0 References: <20201208031609.C8CC52926414@ary.qy> In-Reply-To: From: Brandon Long Date: Wed, 9 Dec 2020 15:37:19 -0800 Message-ID: To: Michael Thomas Cc: IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000fd625b05b6108a80" Archived-At: Subject: Re: [dmarc-ietf] A-R results for DMARC X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Dec 2020 23:37:34 -0000 --000000000000fd625b05b6108a80 Content-Type: text/plain; charset="UTF-8" On Wed, Dec 9, 2020 at 2:27 PM Michael Thomas wrote: > > On 12/8/20 4:51 PM, Brandon Long wrote: > > > > On Mon, Dec 7, 2020 at 8:31 PM John R Levine wrote: > >> On Mon, 7 Dec 2020, Murray S. Kucherawy wrote: >> > The original intent back in RFC 5451 was to relay only those details >> that >> > an MUA might care about, such as the DKIM result (so you can display >> > something representing a "pass" or "fail" on a message) and maybe the >> > domain name found in a passing signature (an early shot at caring about >> > alignment when rendering a message). ... >> >> I suppose but 5451 also says it might be useful to message filters. >> > > Right, there are clearly MUAs that do some amount of spam filtering, so > disposition > of p=quarantine would seem to be useful for that. > > Is there any evidence for that though? I would assume that the folks on > this list use a diverse set of MUA's and would be in a position to tell us > if some of them do. I'm guessing by your statement that gmail doesn't do > anything different. > Gmail does put messages with disposition quarantine into the spam label, but we don't rely on the A-R header to pass that information from the smtp transaction to the mailbox. At least the Mac Apple Mail client did have a client-side spam filter, looks like it probably still does: https://support.apple.com/guide/mail/reduce-junk-mail-mlhlp1065/mac Does it handle spf/dkim/dmarc in any way? I don't know. Brandon --000000000000fd625b05b6108a80 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Dec 9, 2020 at 2:27 PM Michae= l Thomas <mike@mtcc.com> wrote:<= br>
=20 =20 =20


On 12/8/20 4:51 PM, Brandon Long wrote:
=20


On Mon, Dec 7, 2020 at 8:31 PM John R Levine <johnl@taugh.com> wrote:
On Mon, 7 Dec 2= 020, Murray S. Kucherawy wrote:
> The original intent back in RFC 5451 was to relay only those details that
> an MUA might care about, such as the DKIM result (so you can display
> something representing a "pass" or "fail&qu= ot; on a message) and maybe the
> domain name found in a passing signature (an early shot at caring about
> alignment when rendering a message). ...

I suppose but 5451 also says it might be useful to message filters.

Right, there are clearly MUAs that do some amount of spam filtering, so disposition
of p=3Dquarantine would seem to be useful for that.

Is there any evidence for that though? I would assume that the folks on this list use a diverse set of MUA's and would be in a position to tell us if some of them do. I'm guessing by your statement that gmail doesn't do anything different.

Gmail does put messages with disposition quarantine into the = spam label, but we don't rely on the A-R header to pass that informatio= n from the smtp transaction to the mailbox.

At lea= st the Mac Apple Mail client did have a client-side spam filter, looks like= it probably still does:

Does it handl= e spf/dkim/dmarc in any way?=C2=A0 I don't know.

Brandon=C2=A0
--000000000000fd625b05b6108a80-- From nobody Wed Dec 9 15:48: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 82CE63A0651 for ; Wed, 9 Dec 2020 15:48:20 -0800 (PST) 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 u5ICU2kUv6Kg for ; Wed, 9 Dec 2020 15:48:18 -0800 (PST) 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 80A2E3A064A for ; Wed, 9 Dec 2020 15:48:18 -0800 (PST) Received: from NAM10-BN7-obe.outbound.protection.outlook.com (mail-bn7nam10lp2103.outbound.protection.outlook.com [104.47.70.103]) by smtpauth1.wiscmail.wisc.edu (Oracle Communications Messaging Server 8.0.2.4.20190812 64bit (built Aug 12 2019)) with ESMTPS id <0QL3000SKJGGLW30@smtpauth1.wiscmail.wisc.edu> for dmarc@ietf.org; Wed, 09 Dec 2020 17:48:17 -0600 (CST) 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.12.9.233918, AntiVirus-Engine: 5.79.0, AntiVirus-Data: 2020.11.17.5790001, SenderIP=[104.47.70.103] ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ig+0YbQH6OSk29tUqd+2ISAcFN/v6YFBZmr15mJq1gByRZr61KZZTe9t5O/Fr+Zjb7wQ8Bfa39nbIv6+Rsecn39BKFzASJC2FxNv3C7bYjmopvJlmMps/jf06QbASF4rZGF/2A/9pPCsKj6Zb5bOcIFpeCfkE4N+fB9pug09CCDYuo/u7zMzuGDxHbFlm3m1feDC5qBc9Mtw6UCe1VN/BKOq0cMhIUWCcIU1cRBAh2Cwoomn6zO5Kc39UaOJ8gK7CwIr3kGMWZXSrc7bSbXK0B7RHi0ecMV6QWF5TcWMJgxQD/VpsTCy4RVjV4rjezBkCAFcQCnkiTeF+lAUkm0k4w== 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=j3PTzX2Y0cqjNICgonblMb67wdMl+2EntP0N3F7obIo=; b=QbUCkN9MD6pspn7qOmJ4sIgaYFfkJAppUGntUS2u1C10cKZQ0Ei+6axXX4IF+6W79bVQhX5aIvyAttOMsaCToWKXAww4tJFDMJP75yMgRs0OtzWoaGziy4TRVM+96gFcwj746fyNiWDg16Uquvui7/z2lXfGM74D2zfA4sKV+wn6RSYRKKSUIDKwyBhmsSHdzCK+2RpK47ABQI6Ij+fB825eUrTwcJQSBjW5R/vHY+zI1wpniUrETGogxcwy1aGUDjZVWp0F9GDzdKOKfZ0dWVFfY4qQSYyOHrN30LFtfxK8L1FFajAdSVRolP/EAoXkKPjHFKeyDlyAiUzuPlYLoA== 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=j3PTzX2Y0cqjNICgonblMb67wdMl+2EntP0N3F7obIo=; b=RdynMT5dKb2+eZYGtdd3EjlprUwYYdbsNE0zxgtiS3XqCyOziQ1YqlPgY57SI+UrqdfyJMRAUsQtnj6y/wC4nmbySYOmI0mF2sxP38nRpKi6AOdQTfm8iya1QtAwW0AHQWfcGiKZdkcxJ1IKBRKjrAH6EiCjtqjOtRXeYv6ECb0= Received: from PH0PR06MB7061.namprd06.prod.outlook.com (2603:10b6:510:21::8) by PH0PR06MB7654.namprd06.prod.outlook.com (2603:10b6:510:53::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3654.12; Wed, 9 Dec 2020 23:48:15 +0000 Received: from PH0PR06MB7061.namprd06.prod.outlook.com ([fe80::51ec:c9cd:3511:1bcc]) by PH0PR06MB7061.namprd06.prod.outlook.com ([fe80::51ec:c9cd:3511:1bcc%6]) with mapi id 15.20.3632.021; Wed, 9 Dec 2020 23:48:15 +0000 To: dmarc@ietf.org References: <609e1c9b-cc4d-d7d1-0fa8-79f515c1eee4@tana.it> From: Jesse Thompson Message-id: <5b50a8ee-8f35-8ca1-b03d-eb4f8e697108@wisc.edu> Date: Wed, 9 Dec 2020 17:48:12 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 In-reply-to: <609e1c9b-cc4d-d7d1-0fa8-79f515c1eee4@tana.it> Content-type: text/plain; charset=utf-8 Content-language: en-US Content-transfer-encoding: 8bit X-Originating-IP: [47.12.96.133] X-ClientProxiedBy: CH2PR14CA0044.namprd14.prod.outlook.com (2603:10b6:610:56::24) To PH0PR06MB7061.namprd06.prod.outlook.com (2603:10b6:510:21::8) MIME-version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [10.0.2.111] (47.12.96.133) by CH2PR14CA0044.namprd14.prod.outlook.com (2603:10b6:610:56::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3654.12 via Frontend Transport; Wed, 9 Dec 2020 23:48:14 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: dfb1b734-604e-4902-f511-08d89c9ce5c6 X-MS-TrafficTypeDiagnostic: PH0PR06MB7654: 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: EUZxmYfAEg356Fq1uPLXHUD8lCpq6KG5MgQNQPvnt15E68YukgqXWNsTfy3AZMJUd/OO0ji8JKVeapwiZXh0m357NZDqqZPqvAGydQgDABht4VLtRF7TcWPNwmgXpXPhZgJvAZ5+X7xs12hfKeztCAliBtgouio9T82Tr+7SphBM/pTxXZDIhWNbfcEl3yHMvIqJJOVrpsO4tXx4jx4Buj1N6oX8FBvbZATG7PTZ+2vHycTHwytO8FqBFwC0IEIQ75Q5M6QHo1iy0o2oG6byA9+TgU1ZA7dsrNA0+jCH1wlv4UjbktQv5txB+1+kIdTDR4lSXAU7zhiZprr7uui+eBxVRtsadvwOJjRygIbZov9ExB/Cchp4ca6PydINhIhbpLXwThT/QjawsgihGIf6jENUwHSKUM2WNCcYnD6W/HM= X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:PH0PR06MB7061.namprd06.prod.outlook.com; PTR:; CAT:NONE; SFS:(376002)(346002)(136003)(366004)(186003)(26005)(2906002)(86362001)(16526019)(36756003)(75432002)(2616005)(66556008)(66476007)(956004)(66946007)(31696002)(31686004)(5660300002)(8936002)(6486002)(44832011)(8676002)(6916009)(786003)(508600001)(66574015)(16576012)(53546011)(83380400001)(45980500001)(43740500002); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: =?utf-8?B?UFFmczZzOFp6NExNakYwTGhFSVhiVUZidUVSUWVLZ0FkMFVSam0xKzlpajFK?= =?utf-8?B?dEZuKzdMTnVQdW0xMzFDWGE0VU1JYXNZQWc4ZUtLcWlsR2lNZlBEYzkvOU1E?= =?utf-8?B?ejJ5VUxpN1ZVc3V5MVdOMXNSUVkvcUFKZVRETENRUklTb1dZUDF3R3RIY0Vr?= =?utf-8?B?SkZSUnNnZ1ZtalliUGZiVTl3emcycVRTZ0NSN2xaeWUxOWNQR3AwT2l2czJZ?= =?utf-8?B?YnRtbmNKazFGWEZsV0Z1U25nd1NpaFFrRjZvQWxMcXA3Z3E5b3R5emdGQUhU?= =?utf-8?B?aWh2eDVQQXkzekxZT0ozSUhNTXMxQzdhSTkrZlROeE9pM2VCZFNSNkllU0I0?= =?utf-8?B?L05QeGJiWm5MN2hvTEEyVlVDN2g2ck90T0ZBVjRSeFJ6ZGVNQmxFZWNqOU5l?= =?utf-8?B?dEUrYnlCRkxhT0NtNmlNTFJweGp3ZDJKTldJRmdVeUpLVUR4NjRJVW5VRE9B?= =?utf-8?B?UDVTVXJJSWZwcjBiRnhJWlNjYjRhVmpsb0ZZS2FsZTF1ZjhTcmdxYmxaMDN4?= =?utf-8?B?QUZvalJpRGljYm00ZUMzdGtUYTZ3VGluYlBSaEc0Um4rQy9peXhLSloycWVL?= =?utf-8?B?MWhxeksxM2JKZTE3L1k1QmxoQkVIaE9IVjZEYUdkeWl0TFUxSk5Wd2Z0UjZv?= =?utf-8?B?cDl6d3M2U1JGc3lXK256NXN2U1ArL1hGOEZoR1JzdUVGWHJUbWlWT2lhQXFm?= =?utf-8?B?UklKZzlVWnA4dEtDTjVTSGRIVzkzUnVkbDJsbTlrRVozR0RjeUs2UzlHK2Fk?= =?utf-8?B?QVd6Ym5iYndCYmRwNmZhZnpIRzYvOG1hZzFIcWRUc3U2YVRXYXVCNHphaFN5?= =?utf-8?B?MGNDbGVFd3RzN3dyNVorQzlCbEg5eTJNQlhxV2E1QkZXQ3BYMmxiYnk3RFJy?= =?utf-8?B?d2paOGpHcVZXNUFlMUtDYnlEZHdiSGwyeTZJVklmRzUzQkUvZkREY3pubHpW?= =?utf-8?B?VUxOeTRwaitDSzRlWmRObXZwbjJUUGQxY3ZvN2ZpZVdhUUk1ZFN3UjBDTlc1?= =?utf-8?B?Vk9LblljNWpjeUFldTJUZzdxc2N0WnRjVmJMVkJXVVVRQ2lBNXduRWZLaTJV?= =?utf-8?B?ZDhRbFcxMG5NUkh0V0hIMHoraUtoVFUyTWdSMjh2cTFoYVl2Sm1mMUpOdjBt?= =?utf-8?B?NUZoZ3E4b280aFhoL2kycnJmTlBoVmJoQWtyK2JKV1M4d2kydElHWGp1NGpt?= =?utf-8?B?SHFNYm1NTDF5MW5iTm9kMDBVRW9iNHMvdkpmeTBQN0tNdTEwWHRMN0xGeGly?= =?utf-8?B?bU1SOGhZSzU0WkVoMEhqamIzdUhkRHJCVVJPYk1Eb1dxbDhpVGtpcDcxSzNw?= =?utf-8?Q?EA7UYYX4LPOeWt/WK3o/XeIpy1DrgD+IiD?= X-OriginatorOrg: wisc.edu X-MS-Exchange-CrossTenant-AuthSource: PH0PR06MB7061.namprd06.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 Dec 2020 23:48:15.5244 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 2ca68321-0eda-4908-88b2-424a8cb4b0f9 X-MS-Exchange-CrossTenant-Network-Message-Id: dfb1b734-604e-4902-f511-08d89c9ce5c6 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: mcQA43bcx+43n40R1lGRSNOaW4TOKJweBivEYLv7ztiHHGfxqTExVtqzFZ6g/L/xWRuVYzxm05ugQBMGteUpXg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR06MB7654 Archived-At: Subject: Re: [dmarc-ietf] Ticket #61 - Define and add a simplified (redacted) failure report X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 09 Dec 2020 23:48:21 -0000 On 12/9/20 11:07 AM, Alessandro Vesely wrote: > We would like to close this ticket by Dec 23, two weeks from now, so please get on it. > > The ticket text is: > >     It has been asked for a new report type (perhaps a subset of failure >     reports) that provides minimal data from the email (specifically, the >     initial ask is for the to: and from: email addresses only) in order to aid >     identification of the email's destination (and hence, the owner who can >     help with getting it authenticated) without providing other PII. > >     This is a significant use case for large organizations, where the >     departments or other sub-organizations run their own emailing >     infrastructure. This has been specifically requested by multiple >     universities. > > > DMARC failure reporting is based on Authentication Failure Reporting Using the Abuse Reporting Format (RFC 6591), which in turn is based on An Extensible Format for Email Feedback Reports (RFC 5965).  DMARC adds five fields for the second MIME part of the report.  The third part can be either the full message of just the rfc822-headers.  The latter is defined in The Multipart/Report Media Type for the Reporting of Mail System Administrative Messages (RFC 6522), which mentions that Received: fields can also be useful for diagnosing failures.  In any case, private data such as the local part of email addresses can be redacted according to Redaction of Potentially Sensitive Data from Mail Abuse Reports (RFC 6590). > > In order to be useful, reports should contain enough data to discern whether the failed message was abusive, and what stream does it belong to if it wasn't.  Should DMARC Failure Reporting (our document) include some guidance about what parts of the failed message to include and which ones to redact? During our DMARC deployment (and even today) I was frustrated that I could see from aggregate reports that an ESP (or some other type of hosting provider whereby the IP address alone wasn't identifiable enough) was using our domain, but I didn't know who within our organization was a customer of the ESP. Ultimately, I wanted to reach out to the customer and set them up with a subdomain to use with the ESP so they could send branded and DMARC SPF&DKIM-aligned email. Asking the ESP who they're allowing to use our domain was a dead-end because they considered that private customer information (irony!) and they're naturally inclined to make their customers happy by tolerating the use of the domain without complicating matters that may result in possibly losing the customer. Forensic reports are a useful mechanism to find examples of these messages and subsequently track down the customer on our end. Usually, seeing the local part of the address used in the From header (maybe coupled with the Subject) was enough information. I did struggle with the needle-haystack problem with these reports. It was challenging to find what I was looking for, and it was challenging to create a process for going through all of the reports in any meaningful way. Perhaps I didn't really find the right tool for the job, or perhaps the problem wasn't large enough for me to justify finding/developing the right tool. Alternatives: - Assuming that all ESPs were cooperative to inquiries from domain owners, and there was a consistently-used internal identifier that could be referenced that doesn't directly disclose publicly identifiable information about the customer, then that might be all of the forensic information that I would need. But fall back to From/Subject, otherwise. - SPF macros can be constructed such that the envelope information is sent back to the domain owner via DNS queries. This tactic is handy only if there is something identifiable in the local part of the return path. The downside to this tactic is that you're spraying unencrypted identifiable information across the internet. I guess that I'm leaning towards encouraging redacted reports with some minimally identifiable information. The reporters still have the option to not send reports (or redact however they see fit), and domain owners have the option to not request reports if they are concerned about privacy. The potential downside to not having failure reports at all is that potentially less secure/private mechanisms may be adopted due to demand (such as SPF macros, sketchy data warehousers, etc). I did purposefully ignore the use case for using DMARC failure reports to track direct domain abuse, which I assume is a valid use case and should be considered in more depth. I just don't have a direct experience using that data in any meaningful way. Perhaps it could be used in a way that articulates the *actual* amount of direct domain spoofing being used by malicious actors, as opposed to aggregate reports which only gives you IP addresses (which may be enough if cross referenced with reputation lists). Obviously, if you rely on the full details of the failure report to build anti-spam heuristics, then you wouldn't want the reports redacted. But if you are in that business, I assume that spam traps work better anyway. >From the original ticket, I am failing to completely understand why "aid identification of the email's destination" is more useful than identifying the [true] origin. I suppose it could be useful for organizations who want to validate the use case (make sure they aren't sending unsolicited messages, etc) before adding another server to SPF (without talking to them?). That's just not something we do, since we have a Holy Roman Empire and let people do whatever they want with their own subdomains. Jesse From nobody Wed Dec 9 16:05: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 31DF93A07B3 for ; Wed, 9 Dec 2020 16:05:08 -0800 (PST) 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 3G-DgZzNN7LL for ; Wed, 9 Dec 2020 16:05:05 -0800 (PST) Received: from mail-ua1-x936.google.com (mail-ua1-x936.google.com [IPv6:2607:f8b0:4864:20::936]) (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 54EC43A07A0 for ; Wed, 9 Dec 2020 16:05:05 -0800 (PST) Received: by mail-ua1-x936.google.com with SMTP id t15so1120729ual.6 for ; Wed, 09 Dec 2020 16:05:05 -0800 (PST) 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=AewpJCkC3H2R+Kwif4uJ4i+Om5HJ5dQxSnwampSM0zY=; b=Y4U26G4ZPA7VapnWYPGHj8phMeorvNdN+hT1FJbET310DFlO5/bOMHYjFUCOHxpPGv vERcUMGtytPdSlS109kfU6thYw7XYiK8g3g/67epH4nBAU51Ei5Yg7HV6A1OhkAPHPBd uHLhLycTjwPes1joNNscu2PZfrgclxOKl8ysse+ee1fSSL6C/1fRhoWTZycR+85r3wRi huluq8XPsPAUarPoApw45vXaXMQijyeqeDqyp7Xr67QiwVGlNmvbJzQVGfohWuWdOMqa kYL5ULzOnNSQOkwlpYXnctOAq3TIfXr4NAxum15AvAKzZdke4Sqh/6O7hRxgWWoQO85p KCOA== 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=AewpJCkC3H2R+Kwif4uJ4i+Om5HJ5dQxSnwampSM0zY=; b=TgZRx6GXRJIvz+C69JP7VfeX/vGwr2f8nP6r3m5HEOMlYD77oYL01XVyVK2IjyjY5g cDix2sghClclf8yKVXSXAOjFzBlpGaX/zgGmDI3GsMwQ4mr5um07IOIoROjw62w6GKbe DBwpcMKDUDP4X0uTEm+ZeBOuqTX08pZEAOTTA8Im07EnHgssFSdfSzdtq0QH/x874Mlv 1Ua1ZCWXxwDMitTePkM6FO2dZjFcZqfXctFXFT5yfvRwx89Rthklc+xvLiKukZKJKLuh nhldANraTtUBctzpUKlBm1DIBuqlv6GMXVgfYKrLslr62eGXbZ6nch0OPKFstg2hKa4T SQ4w== X-Gm-Message-State: AOAM532o0Ziz6hUUzVsDKSZq3aFQMnTkxnRI/60TcAUoQKT04bbMkfdQ Q4VxBoHT01FR/6fgR9LL4VH7t4zUfQL3SUUorPel8l8Jzg== X-Google-Smtp-Source: ABdhPJzJ3WsnFihB/mgTBgx05T07Cq97s/Hc6v3GZWfZFbh/ex3hmSOYNSiAAudtwD2+u0I/t99CBlQn/LFNZ2pdANY= X-Received: by 2002:ab0:55da:: with SMTP id w26mr4668819uaa.31.1607558704079; Wed, 09 Dec 2020 16:05:04 -0800 (PST) MIME-Version: 1.0 References: <5C559553-3F45-494D-9714-F7BC47BB82FF@wordtothewise.com> <2F1BED43-5AE5-42BC-AA45-67C5FDAF6CB8@wordtothewise.com> In-Reply-To: From: Brandon Long Date: Wed, 9 Dec 2020 16:04:51 -0800 Message-ID: To: Todd Herr Cc: IETF DMARC WG Content-Type: multipart/alternative; boundary="00000000000083856805b610eda3" Archived-At: Subject: Re: [dmarc-ietf] Ticket #39 - remove p=quarantine X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 10 Dec 2020 00:05:08 -0000 --00000000000083856805b610eda3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Dec 3, 2020 at 6:22 AM Todd Herr wrote: > On Thu, Dec 3, 2020 at 4:28 AM Laura Atkins > wrote: > >> >> >> On 3 Dec 2020, at 06:03, Jim Fenton wrote: >> >> On 2 Dec 2020, at 1:47, Laura Atkins wrote: >> >> p=3Dquarantine is quite useful, particularly for those folks who are try= ing >> to get to a p=3Dreject state. >> >> In practice, senders who publish p=3Dnone don=E2=80=99t find all of the = indirect >> mail flows as some mailing lists do nothing to transform the 5322.from >> address for a p=3Dnone policy. Senders have found that when they switch = from >> p=3Dnone to p=3Dquarantine pct=3D0 they regularly find mail that was not= failing >> for a p=3Dnone. >> >> >> I=E2=80=99m really confused by this. It sounds like the 5322.from addres= s >> rewriting is creating additional errors that didn=E2=80=99t exist before= hand, and >> that=E2=80=99s the opposite of the intended purpose. Isn=E2=80=99t the p= urpose of rewriting >> the 5322.from address to change the domain to that of the mediator, whic= h >> should redirect reporting to the mediator rather than the original sende= r? >> >> >> What I am trying to say is that as I understand it from the folks who >> professionally deploy DMARC, they regularly use p=3Dquarantine pct=3D0 a= s part >> of the deployment process. There are DMARC failures that go undetected i= n a >> p=3Dnone situation but that is detected in a p=3Dquarantine pct=3D0 sit= uation. >> My understanding was this was related to indirect flows through mailing >> lists and how mailing lists are handling the header transformation but i= t=E2=80=99s >> possible I got that piece incorrect. >> >> > Time was (and may still be) that there was a very specific type of mailin= g > list for which p=3Dquarantine, pct=3D0 was required to get accurate DMARC > reporting, and that was for mail that transited Google groups. There've > been a couple of public discussions of the topic over on mailop, includin= g > a thread from April 2018 with the subject of "DMARC p=3Dquarantine pct=3D= 0". > Right, to be clear what is going on: Google Groups only does 5322.From rewriting if the domain is p=3Dquarantine or p=3Dreject, it ignores the value of pct because it can't know whether th= e receiver will apply pct or not to that specific message. It doesn't apply 5322.From rewriting to p=3Dnone domains so as to reduce th= e amount of rewriting it does. Because we don't do the rewriting at p=3Dnone, the dmarc reports that peopl= e get at p=3Dnone will show the messages transiting groups failing dmarc. When you switch to p=3Dquarantine pct=3D0, no one should apply quarantine (= so it's equivalent to p=3Dnone), but Groups will start rewriting, thereby removing all of those failures from your reports. Yes, you won't see those messages in the reports at all anymore because they are no longer using your domain. This isn't ideal, it means reports at p=3Dnone for many domains are very noisy and so harder to use to find what needs to be fixed before going to p=3Dquarantine. There's a trade-off between how best to support domains wh= o are in p=3Dnone and making it easier for domains to progress to p=3Dquarant= ine and p=3Dreject. Even without this quirk for Groups, I wouldn't remove pct. I think controlled rollouts and not knife-edge changes is good practice. I see this thread is actually for removing p=3Dquarantine, I'm voting again= st removing it. Even if we think that domains that use DMARC should all progress to p=3Dreject (or even that most domains should), progressive changes and rollouts make these things possible, and p=3Dquarantine is a safer step than p=3Dreject. There is potentially an argument from the other threads where a domain owner could instead assign a level to a domain indicating how badly they think that abuse of the 5322.From of this domain is, and then the RFC could indicate that receivers SHOULD/MAY treat failures at different threat levels by rejecting or quarantining messages. That would definitely lead to a level of indirection in the progression of changes, since a domain's threat level doesn't normally change... but adding yet another tag for say confidence or rollout level on top of pct starts to really seem like overkill. lvl=3Dhigh confidence=3Dmedium pct=3D0 (My mail should be protected, I'm only part way through ensuring that it is, and this level of confidence is at 0% rollout which is equal to 100% at the lower level) Brandon --00000000000083856805b610eda3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Dec 3, 2020 at 6:22 AM Todd H= err <todd.herr=3D40vali= mail.com@dmarc.ietf.org> wrote:
On Thu, Dec 3, 202= 0 at 4:28 AM Laura Atkins <laura@wordtothewise.com> wrote:

On 3 Dec 2020, at 06:03, Jim Fento= n <fenton@bl= uepopcorn.net> wrote:

On 2 Dec 2020, at 1:47, Lau= ra Atkins wrote:

p=3Dquarantine is quite u= seful, particularly for those folks who are trying to get to a p=3Dreject s= tate.

In practice, senders who publish p=3Dnone don=E2=80=99t find a= ll of the indirect mail flows as some mailing lists do nothing to transform= the 5322.from address for a p=3Dnone policy. Senders have found that when = they switch from p=3Dnone to p=3Dquarantine pct=3D0 they regularly find mai= l that was not failing for a p=3Dnone.

I=E2=80=99m real= ly confused by this. It sounds like the 5322.from address rewriting is crea= ting additional errors that didn=E2=80=99t exist beforehand, and that=E2=80= =99s the opposite of the intended purpose. Isn=E2=80=99t the purpose of rew= riting the 5322.from address to change the domain to that of the mediator, = which should redirect reporting to the mediator rather than the original se= nder?

What I am trying to s= ay is that as I understand it from the folks who professionally deploy DMAR= C, they regularly use p=3Dquarantine pct=3D0 as part of the deployment proc= ess. There are DMARC failures that go undetected in a p=3Dnone situation bu= t that is detected in a p=3Dquarantine =C2=A0pct=3D0 situation.=C2=A0 My un= derstanding was this was related to indirect flows through mailing lists an= d how mailing lists are handling the header transformation but it=E2=80=99s= possible I got that piece incorrect.=C2=A0


Time was (and may still be) that there wa= s a very specific type of mailing list for which p=3Dquarantine, pct=3D0 wa= s required to get accurate DMARC reporting, and that was for mail that tran= sited Google groups. There've been a couple of public discussions of th= e topic over on mailop, including a thread from April 2018 with the subject= of "DMARC p=3Dquarantine pct=3D0".=C2=A0

Right, to be clear what is going on:
G= oogle Groups only does 5322.From rewriting if the domain is p=3Dquarantine = or p=3Dreject, it ignores the value of pct because it can't know whethe= r the receiver will apply pct or not to that specific message.
It doesn't apply 5322.From rewriting to p=3Dnone domains so as to red= uce the amount of rewriting it does.

Because we do= n't do the rewriting at p=3Dnone, the dmarc reports that people get at = p=3Dnone will show the messages transiting groups failing dmarc.
<= div>
When you switch to p=3Dquarantine pct=3D0, no one should apply quar= antine (so it's equivalent to p=3Dnone), but Groups will start rewritin= g, thereby removing all of those failures from your reports.=C2=A0 Yes, you= won't see those messages in the reports at all anymore because they ar= e no longer using your domain.

This isn't ideal, it means report= s at p=3Dnone for many domains are very noisy and so harder to use to find = what needs to be fixed before going to p=3Dquarantine.=C2=A0 There's a = trade-off between how best to support domains who are in p=3Dnone and makin= g it easier for domains to progress to p=3Dquarantine and p=3Dreject.
=

Even without this quirk for Groups, I wouldn't remove pct.=C2= =A0 I think controlled rollouts and not knife-edge changes is good practice= .

I see this thread is actually for removing p=3Dquarantine, I'm= voting against removing it.=C2=A0 Even if we think that domains that use D= MARC should all progress to p=3Dreject (or even that most domains should), = progressive changes and rollouts make these things possible, and p=3Dquaran= tine is a safer step than p=3Dreject.

There is potentially an argume= nt from the other threads where a domain owner could instead assign a level= to a domain indicating how badly they think that abuse of the 5322.From of= this domain is, and then the RFC could indicate that receivers SHOULD/MAY = treat failures at different threat levels by rejecting or quarantining mess= ages.=C2=A0 That would definitely lead to a level of indirection in the pro= gression of changes, since a domain's threat level doesn't normally= change... but adding yet another tag for say confidence or rollout level o= n top of pct starts to really seem like overkill.

lvl=3Dhigh confide= nce=3Dmedium pct=3D0

(My mail should be protected,= I'm only part way through ensuring that it is, and this level of confi= dence is at 0% rollout which is equal to 100% at the lower level)

Brandon
--00000000000083856805b610eda3-- From nobody Wed Dec 9 16: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 8B39F3A0888 for ; Wed, 9 Dec 2020 16:12:33 -0800 (PST) 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 kwgN3Emkk1op for ; Wed, 9 Dec 2020 16:12:31 -0800 (PST) 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 D520A3A09CC for ; Wed, 9 Dec 2020 16:12:30 -0800 (PST) Received: by mail-vs1-xe32.google.com with SMTP id r24so1919785vsg.10 for ; Wed, 09 Dec 2020 16:12:30 -0800 (PST) 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=YzowFg+2X8k54S1OMcmV742PCltHLZp4UHI5bJP9kD4=; b=o7J3F5OBA7g8XphgT+z+Mzl3xBxb884H7XL94hqjRazk4S21gbAJmydKqIkftBGboW gKTXOQz/o/KiCP1aeqeoGYCSwoIvJ68xPn+9v6hF/YyyJeQyt4ALFQ1QRg7WsWYrOJQe eJDdilsHHUbJl7S1gh349/NNuBlc+ULZJfsXXnIILvjAs6cY0T3St0OHyhwv5TcDT0ya cG6x4Roab6thjOkfsOjlQGSNAp9KdklISVy48afFUPT67aO0gFF7J5htrP6n2nm9AxY0 eD7sW/r7X4rWu0Z88nsUhpTm3ahWmBTMLqq8qF9SEQ94p2wlQZvZwN4WcvDEEN04T1um /yYQ== 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=YzowFg+2X8k54S1OMcmV742PCltHLZp4UHI5bJP9kD4=; b=FlLw3GTeikGAlV/fHgALu+YPP1dpFW7cz2TlWs/taK3xUF2csT8WRxszhQAhJ17ig8 AuhHwa3k4tNTRH6vsg/EqUWU3pc/xE1R7vuSR/3EhKgeCCANBhRmPmE21pY7oox9s5Ho ZRf6dqV4YZxRMr9r8uTp6xVtiCBzijemhFLxyKduWihOUW22nLrvQXiUYhl+oycmPZdn oCSUwxNCNLwk4d/djcO8PhgjJIY7PlAR/m2e0gmaceJ/hCGIcoGKNuHJOZa4WKFGu+92 bHF97aXRphc0fY6gkP5fpuliLRUAovJe08t4eeBaFW+DSQW9KPBG71irfLKOQorWSmk1 ZVbQ== X-Gm-Message-State: AOAM530s11pobko7WwptKZhjhE7MZCUA52RMA+oAz8WDwCzkoMIpDPhU xx6hTRLNMWHh8aYvh0qPPFUbaQaySKS4izYfNzRyiGqkiA== X-Google-Smtp-Source: ABdhPJwEei8ej3XxzPDuvEy+XEFMcQQ8FxAfywRQZ4/dAEEXh8uNjt99RUVaE+4PIozSDds8OIxXJGKfeFAY/rpvx24= X-Received: by 2002:a67:df8b:: with SMTP id x11mr4914065vsk.37.1607559149635; Wed, 09 Dec 2020 16:12:29 -0800 (PST) MIME-Version: 1.0 References: <609e1c9b-cc4d-d7d1-0fa8-79f515c1eee4@tana.it> <5b50a8ee-8f35-8ca1-b03d-eb4f8e697108@wisc.edu> In-Reply-To: <5b50a8ee-8f35-8ca1-b03d-eb4f8e697108@wisc.edu> From: Brandon Long Date: Wed, 9 Dec 2020 16:12:16 -0800 Message-ID: To: Jesse Thompson Cc: IETF DMARC WG Content-Type: multipart/alternative; boundary="00000000000012424a05b611080f" Archived-At: Subject: Re: [dmarc-ietf] Ticket #61 - Define and add a simplified (redacted) failure report X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 10 Dec 2020 00:12:34 -0000 --00000000000012424a05b611080f Content-Type: text/plain; charset="UTF-8" On Wed, Dec 9, 2020 at 3:48 PM Jesse Thompson wrote: > On 12/9/20 11:07 AM, Alessandro Vesely wrote: > > We would like to close this ticket by Dec 23, two weeks from now, so > please get on it. > > > > The ticket text is: > > > > It has been asked for a new report type (perhaps a subset of failure > > reports) that provides minimal data from the email (specifically, the > > initial ask is for the to: and from: email addresses only) in order > to aid > > identification of the email's destination (and hence, the owner who > can > > help with getting it authenticated) without providing other PII. > > > > This is a significant use case for large organizations, where the > > departments or other sub-organizations run their own emailing > > infrastructure. This has been specifically requested by multiple > > universities. > > > > > > DMARC failure reporting is based on Authentication Failure Reporting > Using the Abuse Reporting Format (RFC 6591), which in turn is based on An > Extensible Format for Email Feedback Reports (RFC 5965). DMARC adds five > fields for the second MIME part of the report. The third part can be > either the full message of just the rfc822-headers. The latter is defined > in The Multipart/Report Media Type for the Reporting of Mail System > Administrative Messages (RFC 6522), which mentions that Received: fields > can also be useful for diagnosing failures. In any case, private data such > as the local part of email addresses can be redacted according to Redaction > of Potentially Sensitive Data from Mail Abuse Reports (RFC 6590). > > > > In order to be useful, reports should contain enough data to discern > whether the failed message was abusive, and what stream does it belong to > if it wasn't. Should DMARC Failure Reporting (our document) include some > guidance about what parts of the failed message to include and which ones > to redact? > > During our DMARC deployment (and even today) I was frustrated that I could > see from aggregate reports that an ESP (or some other type of hosting > provider whereby the IP address alone wasn't identifiable enough) was using > our domain, but I didn't know who within our organization was a customer of > the ESP. Ultimately, I wanted to reach out to the customer and set them up > with a subdomain to use with the ESP so they could send branded and DMARC > SPF&DKIM-aligned email. Asking the ESP who they're allowing to use our > domain was a dead-end because they considered that private customer > information (irony!) and they're naturally inclined to make their customers > happy by tolerating the use of the domain without complicating matters that > may result in possibly losing the customer. > > Forensic reports are a useful mechanism to find examples of these messages > and subsequently track down the customer on our end. Usually, seeing the > local part of the address used in the From header (maybe coupled with the > Subject) was enough information. I did struggle with the needle-haystack > problem with these reports. It was challenging to find what I was looking > for, and it was challenging to create a process for going through all of > the reports in any meaningful way. Perhaps I didn't really find the right > tool for the job, or perhaps the problem wasn't large enough for me to > justify finding/developing the right tool. > Of course they are useful. There are a lot of potentially privacy invasive things that are useful. At best, we considered allowing RUF reports for cases where the dmarc domain was the receiver, ie if someone had a message that failed dmarc while sending to the same domain, then presumably the domain admin already has the power to view the message. But, if you limit it to that level, then the domain admin could already theoretically do this themselves by having those messages delivered to some destination to look at them, or setting up their own forwarding rule to their dmarc analysts. Brandon --00000000000012424a05b611080f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Dec 9, 2020 at 3:48 PM Jesse = Thompson <jesse.thompson=3D= 40wisc.edu@dmarc.ietf.org> wrote:
On 12/9/20 11:07 AM, Alessandro Vesely wrote:
> We would like to close this ticket by Dec 23, two weeks from now, so p= lease get on it.
>
> The ticket text is:
>
> =C2=A0=C2=A0=C2=A0 It has been asked for a new report type (perhaps a = subset of failure
> =C2=A0=C2=A0=C2=A0 reports) that provides minimal data from the email = (specifically, the
> =C2=A0=C2=A0=C2=A0 initial ask is for the to: and from: email addresse= s only) in order to aid
> =C2=A0=C2=A0=C2=A0 identification of the email's destination (and = hence, the owner who can
> =C2=A0=C2=A0=C2=A0 help with getting it authenticated) without providi= ng other PII.
>
> =C2=A0=C2=A0=C2=A0 This is a significant use case for large organizati= ons, where the
> =C2=A0=C2=A0=C2=A0 departments or other sub-organizations run their ow= n emailing
> =C2=A0=C2=A0=C2=A0 infrastructure. This has been specifically requeste= d by multiple
> =C2=A0=C2=A0=C2=A0 universities.
>
>
> DMARC failure reporting is based on Authentication Failure Reporting U= sing the Abuse Reporting Format (RFC 6591), which in turn is based on An Ex= tensible Format for Email Feedback Reports (RFC 5965).=C2=A0 DMARC adds fiv= e fields for the second MIME part of the report.=C2=A0 The third part can b= e either the full message of just the rfc822-headers.=C2=A0 The latter is d= efined in The Multipart/Report Media Type for the Reporting of Mail System = Administrative Messages (RFC 6522), which mentions that Received: fields ca= n also be useful for diagnosing failures.=C2=A0 In any case, private data s= uch as the local part of email addresses can be redacted according to Redac= tion of Potentially Sensitive Data from Mail Abuse Reports (RFC 6590).
>
> In order to be useful, reports should contain enough data to discern w= hether the failed message was abusive, and what stream does it belong to if= it wasn't.=C2=A0 Should DMARC Failure Reporting (our document) include= some guidance about what parts of the failed message to include and which = ones to redact?

During our DMARC deployment (and even today) I was frustrated that I could = see from aggregate reports that an ESP (or some other type of hosting provi= der whereby the IP address alone wasn't identifiable enough) was using = our domain, but I didn't know who within our organization was a custome= r of the ESP.=C2=A0 Ultimately, I wanted to reach out to the customer and s= et them up with a subdomain to use with the ESP so they could send branded = and DMARC SPF&DKIM-aligned email.=C2=A0 Asking the ESP who they're = allowing to use our domain was a dead-end because they considered that priv= ate customer information (irony!) and they're naturally inclined to mak= e their customers happy by tolerating the use of the domain without complic= ating matters that may result in possibly losing the customer.

Forensic reports are a useful mechanism to find examples of these messages = and subsequently track down the customer on our end.=C2=A0 Usually, seeing = the local part of the address used in the From header (maybe coupled with t= he Subject) was enough information.=C2=A0 I did struggle with the needle-ha= ystack problem with these reports.=C2=A0 It was challenging to find what I = was looking for, and it was challenging to create a process for going throu= gh all of the reports in any meaningful way.=C2=A0 Perhaps I didn't rea= lly find the right tool for the job, or perhaps the problem wasn't larg= e enough for me to justify finding/developing the right tool.

Of course they are useful.=C2=A0 There are a lot of = potentially privacy invasive things that are useful.

At best, we con= sidered allowing RUF reports for cases where the dmarc domain was the recei= ver, ie if someone had a message that failed dmarc while sending to the sam= e domain, then presumably the domain admin already has the power to view th= e message.

But, if you limit it to that level, then the domain admin= could already theoretically do this themselves by having those messages de= livered to some destination to look at them, or setting
up their = own forwarding rule to their dmarc analysts.

Brand= on=C2=A0=C2=A0
--00000000000012424a05b611080f-- From nobody Wed Dec 9 17:23: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 1FEA83A0A4D for ; Wed, 9 Dec 2020 17:23:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, 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=mtcc.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 L1apTtwUwKem for ; Wed, 9 Dec 2020 17:23:18 -0800 (PST) Received: from mail-pg1-x533.google.com (mail-pg1-x533.google.com [IPv6:2607:f8b0:4864:20::533]) (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 D5CA03A09E0 for ; Wed, 9 Dec 2020 17:23:18 -0800 (PST) Received: by mail-pg1-x533.google.com with SMTP id o5so2625444pgm.10 for ; Wed, 09 Dec 2020 17:23:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mtcc.com; s=fluffulence; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=5KnLGgTpZ4InnU3Tvo6u/TBCl/vKlHlzQwIK5UQQy+k=; b=HFd53E1uVYG7qJnuL3ehJI216Zx/ZerRe1RPRSAjTwI21ghGrbfvLhWLxz+s+9mARn c6+0XDM05dYVeF46031llabWa3IvmTEMyUOf5RpktYhi0B8gceGDuZ0jsKUG9kqXD0Px khcLsH1lVcPjVlb9Lfmo9FrIOC0PgLv0Nsm7poGRBJaYnB2/s1UwSVv9c2G9730f5Pcq /fixXnnA7l6dB8NDaSRqIWeiXsyTOySU5d4r51WbDFjHIXjI0bdu6aWyIdkpxSCkOir0 RWOMub+QEbBuXaB5Ng+Cq3ENHJ8G6hBortz2UPCkqkIR4VkiIe8NlLRsu44LXl3vfBH9 cfjw== 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=5KnLGgTpZ4InnU3Tvo6u/TBCl/vKlHlzQwIK5UQQy+k=; b=R6+nuNcSeIwfTNse9TTH6PK5OalpQaHwGa7v0Bcx0nrrwzajNoJtzpzq+IhneGoMXZ S+SkAfUAKvSs2KN73XRwPpUtyP4uayrFTPG9T9iPDxYcJuhVyPse3Uq5hi39n8rLsTYa rGyMo4AoRzER6IWzVQzwQ1auNafr0x7cMWTT4vIUv5cpkJVxGazLn9gNfJIdOUh391kG 1StKOlyeH3HVkZUVCAzmmaT18+X8IoTcmfgrYcrkXUhHRXIDFWw2V8WkMndYYAEaULuX fURxBmW5mkuZNkM6Xx+9u375ucqttvLXRk1pkDaIYCu4KZZYtI7olFgXCUqLNZHFFeY/ FL6w== X-Gm-Message-State: AOAM531g/LpCEgSDMQHjQZESNpN9Trh05apHoiL+DdNuJ2AoKo13W3PM Ehuu7iULRrIYgckb71oO8CQbu5rbbW35hg== X-Google-Smtp-Source: ABdhPJw0NyTls5fZc3XfNBU6CAqq9qeWUTFK/oWU4N1JZiij76YmHaT+TbaFalh+RVrV6SN0F1GrVA== X-Received: by 2002:a17:90a:f992:: with SMTP id cq18mr4883730pjb.216.1607563392731; Wed, 09 Dec 2020 17:23:12 -0800 (PST) Received: from mike-mac.lan (107-182-41-154.volcanocom.com. [107.182.41.154]) by smtp.gmail.com with ESMTPSA id i11sm3349770pjl.53.2020.12.09.17.23.10 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 09 Dec 2020 17:23:12 -0800 (PST) To: dmarc@ietf.org References: <5C559553-3F45-494D-9714-F7BC47BB82FF@wordtothewise.com> <2F1BED43-5AE5-42BC-AA45-67C5FDAF6CB8@wordtothewise.com> From: Michael Thomas Message-ID: <7b7171dd-b714-e3c0-8f00-7dad58ac90ec@mtcc.com> Date: Wed, 9 Dec 2020 17:23:10 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------9C88C272CDCE8B030E179772" Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] Ticket #39 - remove p=quarantine X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 10 Dec 2020 01:23:20 -0000 This is a multi-part message in MIME format. --------------9C88C272CDCE8B030E179772 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 12/9/20 4:04 PM, Brandon Long wrote: > > > When you switch to p=quarantine pct=0, no one should apply quarantine > (so it's equivalent to p=none), but Groups will start rewriting, > thereby removing all of those failures from your reports.  Yes, you > won't see those messages in the reports at all anymore because they > are no longer using your domain. Is that what's going on with some of the messages I see on this list? That seems pretty awful from a security standpoint. Basically you're engineering a lookalike From address attack. The one big disappointment from my standpoint is that MUA's don't seem to be using auth-res, etc, to do some basic annotation. At least Thunderbird. And I don't recall gmail doing anything either. Mike --------------9C88C272CDCE8B030E179772 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit


On 12/9/20 4:04 PM, Brandon Long wrote:


When you switch to p=quarantine pct=0, no one should apply quarantine (so it's equivalent to p=none), but Groups will start rewriting, thereby removing all of those failures from your reports.  Yes, you won't see those messages in the reports at all anymore because they are no longer using your domain.

Is that what's going on with some of the messages I see on this list? That seems pretty awful from a security standpoint. Basically you're engineering a lookalike From address attack. The one big disappointment from my standpoint is that MUA's don't seem to be using auth-res, etc, to do some basic annotation. At least Thunderbird. And I don't recall gmail doing anything either.

Mike


--------------9C88C272CDCE8B030E179772-- From nobody Wed Dec 9 19:32: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 C2BBB3A0AF9 for ; Wed, 9 Dec 2020 19:32:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.851 X-Spam-Level: X-Spam-Status: No, score=-1.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iecc.com header.b=pL1PhY6Z; dkim=pass (2048-bit key) header.d=taugh.com header.b=GgH/L4oC Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5T42Fnqv4lDo for ; Wed, 9 Dec 2020 19:32:15 -0800 (PST) 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 5E8D13A0B6F for ; Wed, 9 Dec 2020 19:31:57 -0800 (PST) Received: (qmail 11265 invoked from network); 10 Dec 2020 03:31: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:mime-version:content-type:content-transfer-encoding:cleverness; s=2bff.5fd196ab.k2012; bh=OkjjvzKZ7ZL6eKIY8tz/zBjgC0H3Dzfr6hivecdvhdU=; b=pL1PhY6ZIMOvx3tngylPr+L/egs6LRZdmNVFodpo2KBox1oodQANYmjP9c3EjOsd8DvH97kLZMz7y3/q5rKWtZ7xQ5uOzn1X4NxniU8UN42UeQ48u5hWZ+ICFnZM1luMTFECzL7Lc+wSthVeRzECsF6F9hFrWR4LU8XqKQVr6TC6OEQHbLTELKONTD3f7lKZKVTCWvBPTO7eP3FyiRJTKaqvSZ97VZE60T/1LDP1X9WgBq8dy9tz2cv7ek38UvQ14KUUKl31C0vcsnFXezWnKO1XedH1Tbkcdy88kKglKF1CvsMv/vZqMkSAh6lfq4lwOGhYK6YaC7rJ46g5hX4Jnw== DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=2bff.5fd196ab.k2012; bh=OkjjvzKZ7ZL6eKIY8tz/zBjgC0H3Dzfr6hivecdvhdU=; b=GgH/L4oCgNApCJzlk7nqdv5XDtN1Ehu8R/1HbiOyfSnNPiAXx6NuHnmHkGZhjpmuJSOUky2BEdbo8O2JZvamlz+i19UXDajqtirXiCUXbgIEz1wYFSWl4Unz8eQFVe9OmK1UQzYaKJd5LNTIVAUTKu30ZWmiShfRih9/eo+qlKTW9YtUeOp5ZqIKZy9It/mAKTUQ7MdZLyEYNJudRZM/scRTxp4Dq4lUOPWkUp+8NsrdnpwKJixSGzt6zABO/9H02+uhoYab3PikvxgiCrMbeqsArc8Uf4wFOT/WofwuJ9GApp/ZIbVQv6VNdPhDT+RvJg9ed212hlemBFP4OGj9hA== 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; 10 Dec 2020 03:31:55 -0000 Received: by ary.qy (Postfix, from userid 501) id DC28F294BD52; Wed, 9 Dec 2020 22:31:54 -0500 (EST) Date: 9 Dec 2020 22:31:54 -0500 Message-Id: <20201210033154.DC28F294BD52@ary.qy> From: "John Levine" To: dmarc@ietf.org Cc: jesse.thompson@wisc.edu In-Reply-To: Organization: Taughannock Networks X-Headerized: yes Cleverness: minimal Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] Domains and tree walk X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 10 Dec 2020 03:32:24 -0000 In article you write: >I would hesitate to assume that seeing p=none on a domain as an indicator that they are serious about deploying DMARC and reconciling their >own Holy Roman Empire conundrums; rather it's there just to not be seen as lagging behind their peers, justifying funding for more SOC >staff and perhaps buying some tools (*some* of which, hopefully, may be deployed to actually solve the issues identified in the DMARC >reports). I figure they're collecting reports to see where their mail is going. That's what I do. The reports are interesting even if you have no intention of ever publishing a policy other than p=none. >For better or worse, DHS BOD 18-01 mandated that all federal agencies publish p=reject on their domains. Now, *that* must have forced each >agency to figure out how to actually deploy DMARC and deal with the implications. I applaud the tenacity. Hahaha. It means they published SPF and DMARC p=reject records and checked it off. I've been dealing with fairly important mail to my users falling on the floor ever since. R's, John From nobody Wed Dec 9 20:18: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 8A3C63A09F9 for ; Wed, 9 Dec 2020 20:18:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.086 X-Spam-Level: X-Spam-Status: No, score=-2.086 tagged_above=-999 required=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, T_SPF_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 62dxohAodgxU for ; Wed, 9 Dec 2020 20:18:52 -0800 (PST) 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 3FD1B3A09F6 for ; Wed, 9 Dec 2020 20:18:52 -0800 (PST) Received: by mail-vk1-xa31.google.com with SMTP id a4so908053vko.11 for ; Wed, 09 Dec 2020 20:18:52 -0800 (PST) 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=wZUot1u6s2RCeHqmet1KMMemfBrMFiXUQ04/fiuFOes=; b=ZBri38EVTmqLJBM+N4iMtFlclSzL9rtoZQXkd0Q1xvQkz18ltunLPqP0fWKVxy0deP 4sma0G27BdzepEGQKEEcn6txWW1IA3TSzEftNBpu0XxVoHrDPRtqeZjA8LCSOVNjEueZ At6kXQ1bjY8ZHVyeji7y8Saf8XBOHM+2YyBWxGmKqtOHHReZMH53AnZ4WuqHh78IE4dS 6bzMhvmnHLBMvAc0hp4eoqjud4CfPUu7YA3fvR5+/D8JdWV3N2T/J2iFcLhlyJGg0M7V x9tU7ImTCkV9jBo/PU1TtW/6xpxaLIigJe7HWa83FSDEi0PFXg+2Hei1rs2nOEYbYsfG iTiQ== 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=wZUot1u6s2RCeHqmet1KMMemfBrMFiXUQ04/fiuFOes=; b=dTTaDYWyEIOjxHzr164gJButQ8DKyhCaaWkFUPrLrcju/qCc+eKXcXT7B0EGh2AzQB P6OJRRNDtSHlpuDdygPODbtOuHH1jTZLmMlSdaD7ZUa8FLrDqEbPgj6i7r81kISOD9Wt AN71zzGgd3WHZCA0jErH6/R4D0eizMt3aUzfNAFpsbWztZipYkRjS/Yeqgtlm1vj2ayO 2y2jgdHQb3y5ZPRhXcil7mEmt0eaL+k0Z45T4jBdSxs8JFCCvfRHKEOfD/huXFvjCJ0s iHyyoSdlWO1LWW49w+2/71M3aqrzeHDEXhTLtLdnosoVLtJzFZxtLgz3yL4edG7tDkQb z39w== X-Gm-Message-State: AOAM530wH0S+jT1+Xn5BmEVBcgtvSo/nLXO8JcOnOFFLlVogB+N0MEHh KSzow7cvchsA0pR8bjeyoVCLMxgMp8m6w+u/wcwYZjHp X-Google-Smtp-Source: ABdhPJwDA5lKQnnD4SJaS5ir2AaZV0MXUNbGaCbNhapBPxFxIxrO9D5RhPlRpr1UrBIqwz2l90kZoBxSwXrYuN0LsyM= X-Received: by 2002:a1f:1b82:: with SMTP id b124mr6316104vkb.5.1607573930694; Wed, 09 Dec 2020 20:18:50 -0800 (PST) MIME-Version: 1.0 References: <609e1c9b-cc4d-d7d1-0fa8-79f515c1eee4@tana.it> <20201209185246.1D40C29474C4@ary.qy> In-Reply-To: From: "Murray S. Kucherawy" Date: Wed, 9 Dec 2020 20:18:37 -0800 Message-ID: To: IETF DMARC WG Content-Type: multipart/alternative; boundary="00000000000016df9c05b6147999" Archived-At: Subject: Re: [dmarc-ietf] Ticket #61 - Define and add a simplified (redacted) failure report X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 10 Dec 2020 04:18:58 -0000 --00000000000016df9c05b6147999 Content-Type: text/plain; charset="UTF-8" On Wed, Dec 9, 2020 at 1:29 PM Brandon Long wrote: > In today's much more privacy conscious world, should we have RUF reports > in DMARC > at all? > Forensic reports in DMARC are akin to the DKIM failure reporting we added to ARF back in the MARF working group. In fact if you go back and read those RFCs, an ancestor to the "pct=" tag is there. (RFC 6591 and RFC 6651 in particular are what I'm looking at.) Back in the original DKIM era I always found this kind of reporting to be really valuable especially since DKIM can fail for a variety of reasons that are far less obvious than SPF. Being able to get the verifier to tell me exactly what it saw and compare it to what I think I sent was key to getting the implementation right especially in curious corner cases (any of you that remember the DKIM interop event would know what I mean). Seems to me that's still a useful thing to have, at least sometimes. We might say something like: Include support for this, but don't have it on by default. Or even if it's an extension to DMARC and not part of the base protocol, it might be really helpful in some situations. -MSK --00000000000016df9c05b6147999 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Dec 9, 2020 at 1:29 PM Brandon Lo= ng <blong=3D40google.com@= dmarc.ietf.org> wrote:
In today's mu= ch more privacy conscious world, should we have RUF reports in DMARC
at all?

Forensic reports in DMARC are akin to the DKIM failure reporting we= added to ARF back in the MARF working group.=C2=A0 In fact if you go back = and read those RFCs, an ancestor to the "pct=3D" tag is there. (R= FC 6591 and RFC 6651 in particular are what I'm looking at.)
<= div>
Back in the original DKIM era I always found this kind o= f reporting to be really valuable especially since DKIM can fail for a vari= ety of reasons that are far less obvious than SPF.=C2=A0 Being able to get = the verifier to tell me exactly what it saw and compare it to what I think = I sent was key to getting the implementation right especially in curious co= rner cases (any of you that remember the DKIM interop event would know what= I mean).

Seems to me that's still a useful th= ing to have, at least sometimes.=C2=A0 We might say something like: Include= support for this, but don't have it on by default.=C2=A0 Or even if it= 's an extension to DMARC and not part of the base protocol, it might be= really helpful in some situations.

-MSK
=
--00000000000016df9c05b6147999-- From nobody Wed Dec 9 20:29: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 E46A23A0A3B for ; Wed, 9 Dec 2020 20:29:09 -0800 (PST) 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 h8AS51BAlM-5 for ; Wed, 9 Dec 2020 20:29:08 -0800 (PST) Received: from mail-ua1-x929.google.com (mail-ua1-x929.google.com [IPv6:2607:f8b0:4864:20::929]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D831B3A0A2D for ; Wed, 9 Dec 2020 20:29:07 -0800 (PST) Received: by mail-ua1-x929.google.com with SMTP id t19so1289349uaq.1 for ; Wed, 09 Dec 2020 20:29:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=N1mI/SZ5h00kC7RT4zZl1mGympLdTiahHexqd2iEaXk=; b=XmoKTvXm6chwk/u7W0GOxdOYTUwQDDyG8MQ+7c8KaNHSbrFtMnchYu9CkvtZGHVtOC VHxxQ2YjUVJ2tQiLsCkb9ySzyouekvqB5WS/n1f/61sIFxUwimFEdg9hGo+7RrgIUKYg pB+nbtWV/v+nxfJ7hcQTx7DzNx04sgUyscYHxEfj1E4dIkHtmQPEJMeaMewTrNgs+8tQ nu4u/zgjqvZRTGPGRN4Ipg9jjZcXDWyV9wAQM+asirqwf1WgtjM5fYhF3awhoiCD3IUd pwUxBFl9H85exe8ai948J8oIJp9+LUgHjPJh9Ms22SnoJEj791d+Um9WT1EsuGusA/Pa GuKQ== 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=N1mI/SZ5h00kC7RT4zZl1mGympLdTiahHexqd2iEaXk=; b=jVoKMjyqGmdgMHRHIfjqU22pcq0w9eDVRUvNzcor+rdJYTl9plnHJXAdK+A9c8MT+h 43MORLWmklM51TIeSGFoITW0QTHxRUogevzhW7dp22lU6ZpxGN4n++5g+9i9mzHLnUqF hFQj8ztAjhgwEuPmQeORxyt/5lz55LIW2SYEeBT78Qdkt1X3hMXx6lvewiKUmRrLdzUU NnioFADEqzyydQ08PbLKkYaDW/cn6mU0Kd7DmOT/tou2OzhZmmexhlkAVK4T/0cy978I H/pKW8E0IOgwC3kcwypVBdswYMV1qrLFSXiwBHO1DDoew/u+gB+XlzdbfyT3ocCg7bpD F1Ow== X-Gm-Message-State: AOAM532q2XnArV2PHb4R29stzHqct3KMWFq3ubeItWFuV8rakDGux4Cb Cwu4A4qQokGJ4ipA1u4CCpDrO+73m1PqPorV4nwsOj0bBtA= X-Google-Smtp-Source: ABdhPJwl5dSHWzRWapEjGVob2cD/sULVKKCBggWok4FqiLC4/xeIBYLEqNGyVDlgGyYMSeZtrm9KiKtttjZeUnDT2IA= X-Received: by 2002:ab0:648:: with SMTP id f66mr5565239uaf.126.1607574546587; Wed, 09 Dec 2020 20:29:06 -0800 (PST) MIME-Version: 1.0 References: <609e1c9b-cc4d-d7d1-0fa8-79f515c1eee4@tana.it> <20201209185246.1D40C29474C4@ary.qy> In-Reply-To: From: Seth Blank Date: Wed, 9 Dec 2020 20:28:55 -0800 Message-ID: To: IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000ccbb5a05b6149d9f" Archived-At: Subject: Re: [dmarc-ietf] Ticket #61 - Define and add a simplified (redacted) failure report X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 10 Dec 2020 04:29:10 -0000 --000000000000ccbb5a05b6149d9f Content-Type: text/plain; charset="UTF-8" On Wed, Dec 9, 2020 at 8:19 PM Murray S. Kucherawy wrote: > On Wed, Dec 9, 2020 at 1:29 PM Brandon Long 40google.com@dmarc.ietf.org> wrote: > >> In today's much more privacy conscious world, should we have RUF reports >> in DMARC >> at all? >> > > Forensic reports in DMARC are akin to the DKIM failure reporting we added > to ARF back in the MARF working group. In fact if you go back and read > those RFCs, an ancestor to the "pct=" tag is there. (RFC 6591 and RFC 6651 > in particular are what I'm looking at.) > > Back in the original DKIM era I always found this kind of reporting to be > really valuable especially since DKIM can fail for a variety of reasons > that are far less obvious than SPF. Being able to get the verifier to tell > me exactly what it saw and compare it to what I think I sent was key to > getting the implementation right especially in curious corner cases (any of > you that remember the DKIM interop event would know what I mean). > > Seems to me that's still a useful thing to have, at least sometimes. We > might say something like: Include support for this, but don't have it on by > default. Or even if it's an extension to DMARC and not part of the base > protocol, it might be really helpful in some situations. > Speaking as a report processor, never in all my years of helping domain owners use dmarc reports to authenticate their mail has this ever been necessary. As an individual, I feel extremely strongly that failure reports should go away in their entirety. Although Jesse Thompson has outlined a use case that really has no other good solution, and is equally true in other large complicated organizations. However, this problem is mitigated with a tree walk, where you can get the reports to the appropriately localized part of the organization (like, math.wisc.edu, instead of to Jesse at wisc.edu who'd need to hunt things down). As Chair, I've seen relatively strong opinions that people wish for failure reports to remain. More conversation here is useful. For this ticket in particular-- the simplified failure report with only from: and to: addresses speaks to Jesse's exact use case, without any of the other PII that tends to get failure reports in privacy trouble (like body content and attachments). This approach to Jesse's use case should get a fair discussion, separate from whether we want failure reports at all. Seth -- *Seth Blank* | VP, Standards and New Technologies *e:* seth@valimail.com *p:* 415.273.8818 This email and all data transmitted with it contains confidential and/or proprietary information intended solely for the use of individual(s) authorized to receive it. If you are not an intended and authorized recipient you are hereby notified of any use, disclosure, copying or distribution of the information included in this transmission is prohibited and may be unlawful. Please immediately notify the sender by replying to this email and then delete it from your system. --000000000000ccbb5a05b6149d9f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Dec 9, 2020 at 8:19 PM Murray S. = Kucherawy <superuser@gmail.com> wrote:
In today's much more privacy conscious world, = should we have RUF reports in DMARC
at all?<= /div>

Forensic reports in DMARC= are akin to the DKIM failure reporting we added to ARF back in the MARF wo= rking group.=C2=A0 In fact if you go back and read those RFCs, an ancestor = to the "pct=3D" tag is there. (RFC 6591 and RFC 6651 in particula= r are what I'm looking at.)

Back in the or= iginal DKIM era I always found this kind of reporting to be really valuable= especially since DKIM can fail for a variety of reasons that are far less = obvious than SPF.=C2=A0 Being able to get the verifier to tell me exactly w= hat it saw and compare it to what I think I sent was key to getting the imp= lementation right especially in curious corner cases (any of you that remem= ber the DKIM interop event would know what I mean).=C2=A0
=

Seems to me that's = still a useful thing to have, at least sometimes.=C2=A0 We might say someth= ing like: Include support for this, but don't have it on by default.=C2= =A0 Or even if it's an extension to DMARC and not part of the base prot= ocol, it might be really helpful in some situations.

Speaking as a report processor, never in all my= years of helping domain owners use dmarc reports to authenticate their mai= l has this ever been necessary.

As an individual, = I feel extremely strongly that failure reports should go away in their enti= rety. Although Jesse Thompson has outlined a use case that really has no ot= her good solution, and is equally true in other large complicated organizat= ions. However, this problem is mitigated with a tree walk, where you can ge= t the reports to the appropriately localized part of the organization (like= , math.wisc.edu, instead of to Jesse a= t wisc.edu who'd need to hunt things do= wn).

As Chair, I've seen relatively strong opi= nions that people wish for failure reports to remain. More conversation her= e is useful.

For this ticket in particular-- the s= implified failure report with only from: and to: addresses speaks to Jesse&= #39;s exact use case, without any of the other PII that tends to get failur= e reports in privacy trouble (like body content and attachments). This appr= oach to Jesse's use case should get a fair discussion, separate from wh= ether we want failure reports at all.

Seth

--
=

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


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

--000000000000ccbb5a05b6149d9f-- From nobody Wed Dec 9 21:44: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 7B0003A03EF for ; Wed, 9 Dec 2020 21:44:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.85 X-Spam-Level: X-Spam-Status: No, score=-1.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iecc.com header.b=IA249MeT; dkim=pass (2048-bit key) header.d=taugh.com header.b=eAM8uHt9 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tOWbtLE_p_y2 for ; Wed, 9 Dec 2020 21:44:09 -0800 (PST) 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 468A93A03EE for ; Wed, 9 Dec 2020 21:44:08 -0800 (PST) Received: (qmail 38942 invoked from network); 10 Dec 2020 05:44: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:cleverness; s=981c.5fd1b5a7.k2012; bh=uumGUdCZmDgH213GE8AAVa4ptIr8/e1Cs1OJPOFfl+U=; b=IA249MeTsJ3z130tZM/2+XikMQ/C12TqRLU/LLWYypcopgv+JM3LthoRekwPIYwqREM012EPDYcQT/sUurg8ufu1lpQ4rjXDO9ZnCfpXB6lh1clsu0s+wPOa+HKwv1/GGjva18gwjT1L1QlUEVJ3N6XBlQjT4wrg7rwbWbfAZyicV/GOEkZWpts53y5UfjsqoHHi9tXgzId+bn8O9susPPi+lUA8h/aqz9lGiT/GLKJ98aLR8NbeOSEbXmlsA6bgjsIb9aUsN38LURGe2ZdEjm9C+rDZIXhxQ+ijzmAFE0zGpR6srv3hQafDeY7sR65a2BmdIu0akK/IlfJ2b8cM1A== DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=981c.5fd1b5a7.k2012; bh=uumGUdCZmDgH213GE8AAVa4ptIr8/e1Cs1OJPOFfl+U=; b=eAM8uHt9YmenCgiR2FhNWnyEKR+d0d+e9GDAHwBCoEpL6P0IyCJcpp+KWQzpKA/XgMeWhfI/MtXoH/kp+0Vtbr8HXNBQS1B9hYojmZfs9Qo31UHDKB3t24TN93C+Wuellk0QxZvzPDdPpG6L5cHcEBS0B+b5jVbWabpNQtv5LH0zW+gYQrNftTJiCHexbiAQHVts6oLY2zoG6tODVAXX6MTIBc1Kyo6Iok1xbx+wSdT4yblIes97lq6SsYqjv5eEnprgy5UcshISQUWkv6HL1PA4jTHDzziu4lwfYPra5Q5wIZmdSfafhnGe5vMgMYtYAc/Tarbja8Ll0XNqC0ZX9g== 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; 10 Dec 2020 05:44:07 -0000 Received: by ary.qy (Postfix, from userid 501) id 05D5E294F351; Thu, 10 Dec 2020 00:44:06 -0500 (EST) Date: 10 Dec 2020 00:44:06 -0500 Message-Id: <20201210054407.05D5E294F351@ary.qy> From: "John Levine" To: dmarc@ietf.org Cc: seth@valimail.com In-Reply-To: Organization: Taughannock Networks X-Headerized: yes Cleverness: minimal Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] Ticket #61 - Define and add a simplified (redacted) failure report X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 10 Dec 2020 05:44:12 -0000 In article you write: >For this ticket in particular-- the simplified failure report with only >from: and to: addresses speaks to Jesse's exact use case, without any of >the other PII that tends to get failure reports in privacy trouble (like >body content and attachments). This approach to Jesse's use case should get >a fair discussion, separate from whether we want failure reports at all. Having sat in on far too many GDPR discussions, I'm sure that the To and From addresses are exactly the kind of PII that makes lawyers nervous. Keep in mind that there is no guarantee that the entitity getting the reports has any responsibility for either, particularly if a third party is collecting the reports. I don't think this group has any particular expertise in the issues that are likely to make organizations decide whether there is legal risk in sending the reports and whether and how much to redact them. I would leave whole ruf section alone other than perhaps making clearer that the reports are optional and it may be useful to send even if they are heavily redacted. As an example, a report with the Message-ID but no To or From might still be enough for the report recipient to figure out where a message came from while not disclosing any PII. R's, John From nobody Thu Dec 10 00:34: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 1D1C93A0AD3 for ; Thu, 10 Dec 2020 00:34:22 -0800 (PST) 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 LnXwKEzeU871 for ; Thu, 10 Dec 2020 00:34:20 -0800 (PST) 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 035703A0ACB for ; Thu, 10 Dec 2020 00:34:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1607589256; bh=yHT98PRu1AFXL+RCY3F98qZjkpyQ4IesE5EafLDMuJo=; l=1658; h=To:References:From:Date:In-Reply-To; b=AqBg7J8aAoMkEGl6jroEqPi3JveCnUIyRpOa0KwdGw2FOQC+a57H7iJBngyJGSxVH yAFuy8zCTvhP1saB0/1RBeQPF2P+yHxoC7PrIzIBU01o50WJpyvwY3Xtn1+oy9GvZL q5h+xXtmXdTJ7poDSORFrmkVtlpLJeYp2G2jpNXDDCoHzMilXrc5qOhcJ6lnT Authentication-Results: tana.it; auth=pass (details omitted) Original-From: Alessandro Vesely 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.000000005FD1DD88.00001069; Thu, 10 Dec 2020 09:34:15 +0100 To: dmarc@ietf.org References: <20201208031609.C8CC52926414@ary.qy> From: Alessandro Vesely Message-ID: <970e808e-f8b3-474c-79f1-b275f23d2eeb@tana.it> Date: Thu, 10 Dec 2020 09:34:15 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] A-R results for DMARC X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Dec 2020 08:34:22 -0000 On Thu 10/Dec/2020 00:37:19 +0100 Brandon Long wrote: > On Wed, Dec 9, 2020 at 2:27 PM Michael Thomas wrote: >> On 12/8/20 4:51 PM, Brandon Long wrote: >> On Mon, Dec 7, 2020 at 8:31 PM John R Levine wrote: >>> On Mon, 7 Dec 2020, Murray S. Kucherawy wrote: >>>> The original intent back in RFC 5451 was to relay only those details >>>> that an MUA might care about, such as the DKIM result (so you can >>>> display something representing a "pass" or "fail" on a message) and >>>> maybe the domain name found in a passing signature (an early shot at >>>> caring about alignment when rendering a message). ... >>> >>> I suppose but 5451 also says it might be useful to message filters. >> >> Right, there are clearly MUAs that do some amount of spam filtering, so >> disposition of p=quarantine would seem to be useful for that. >> >> Is there any evidence for that though? I would assume that the folks on >> this list use a diverse set of MUA's and would be in a position to tell >> us if some of them do. > > Gmail does put messages with disposition quarantine into the spam label, but > we don't rely on the A-R header to pass that information from the smtp > transaction to the mailbox. As an SMTP filter, zdkimfilter can reject, but it cannot quarantine. That is MDA's territory. It passes quarantine information in an A-R comment[*]. If there was a standard way to convey that info, it could be used by MUAs as well as by any other software not specifically designed around zdkimfilter's idiosyncrasies. Best Ale -- [*] https://www.tana.it/sw/zdkimfilter/zdkimfilter.html#dmarcand From nobody Thu Dec 10 00:55: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 5A3183A0B25 for ; Thu, 10 Dec 2020 00:55:23 -0800 (PST) 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 O6mFolfXpw-n for ; Thu, 10 Dec 2020 00:55:22 -0800 (PST) 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 CAE2D3A0B23 for ; Thu, 10 Dec 2020 00:55:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1607590518; bh=bkFY5BS50J4MGi6UBfFbgQZXbrYQQEIZinCo3ywuUc8=; l=1256; h=To:References:From:Date:In-Reply-To; b=A/N+kcPMNQpUvlGns+yGCeKfL0Km/YhLygzWayG9aIwdk23I7NGh2CWKSd9SCMFAO UPrF56y5IlK7uuKF4wj/YC58OsV4s/nhsLlQBa3YYgdcZLUAyTkkgqoNL1knU4BzJ1 V22HXehLKGCmXHXdCGyp2CHhb0eE+jJS/4aHP7DTM7knAi6GX1Fy6U/3Ogbyh Authentication-Results: tana.it; auth=pass (details omitted) Original-From: Alessandro Vesely 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.000000005FD1E276.000012DC; Thu, 10 Dec 2020 09:55:18 +0100 To: dmarc@ietf.org References: <5C559553-3F45-494D-9714-F7BC47BB82FF@wordtothewise.com> <2F1BED43-5AE5-42BC-AA45-67C5FDAF6CB8@wordtothewise.com> <7b7171dd-b714-e3c0-8f00-7dad58ac90ec@mtcc.com> From: Alessandro Vesely Message-ID: Date: Thu, 10 Dec 2020 09:55:18 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: <7b7171dd-b714-e3c0-8f00-7dad58ac90ec@mtcc.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] Ticket #39 - remove p=quarantine X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 10 Dec 2020 08:55:23 -0000 On Thu 10/Dec/2020 02:23:10 +0100 Michael Thomas wrote: > On 12/9/20 4:04 PM, Brandon Long wrote: >> >> When you switch to p=quarantine pct=0, no one should apply quarantine (so >> it's equivalent to p=none), but Groups will start rewriting, thereby removing >> all of those failures from your reports.  Yes, you won't see those messages >> in the reports at all anymore because they are no longer using your domain. There is a reporting feature of mlm-transform that might be worth considering apart from any indirect mailflow revival. By adding an Original-From: header field —a copy of From: on the first relay— a domain owner can ask to receive aggregate reports even if From: was rewritten by a MLM. > Is that what's going on with some of the messages I see on this list? That > seems pretty awful from a security standpoint. Basically you're engineering a > lookalike From address attack. The one big disappointment from my standpoint is > that MUA's don't seem to be using auth-res, etc, to do some basic annotation. > At least Thunderbird. You need to install DKIM Verifier[*]. It reads A-R and displays some results. Best Ale -- [*] https://addons.thunderbird.net/en-US/thunderbird/addon/dkim-verifier/ From nobody Thu Dec 10 01:42: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 554983A0BED for ; Thu, 10 Dec 2020 01:42:49 -0800 (PST) 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 yQZ-7CXEwmis for ; Thu, 10 Dec 2020 01:42:48 -0800 (PST) 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 03E543A0BEB for ; Thu, 10 Dec 2020 01:42:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1607593364; bh=IQI9B8nANu9JnlddA4EsvF1MhTqHgMlwl4rIrupOqCU=; l=1828; h=To:References:From:Date:In-Reply-To; b=DI4zbb2h+UlyTWMGbx3r2GZ6rbmZBocv/6AVvQAwcleGQ2NNtl7W8YmGbmzJefVwt hfF35P/UDwOVnwG/3tDzHGxjYAdLD4WMU9D4JiUJPJNN5hOzdiu98BPiId+9Wxz11j LmBkfLU18XmdMsxCAJWRjorWMAGmSt+pug766cRriaC4mcwgORG73kcQZwrDz Authentication-Results: tana.it; auth=pass (details omitted) Original-From: Alessandro Vesely 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.000000005FD1ED94.00001838; Thu, 10 Dec 2020 10:42:44 +0100 To: dmarc@ietf.org References: <609e1c9b-cc4d-d7d1-0fa8-79f515c1eee4@tana.it> <20201209185246.1D40C29474C4@ary.qy> From: Alessandro Vesely Message-ID: <661cb10b-91c8-75f7-0b25-8e3a51b97fd1@tana.it> Date: Thu, 10 Dec 2020 10:42:44 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Ticket #61 - Define and add a simplified (redacted) failure report X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 10 Dec 2020 09:42:49 -0000 On Thu 10/Dec/2020 05:28:55 +0100 Seth Blank wrote: > On Wed, Dec 9, 2020 at 8:19 PM Murray S. Kucherawy wrote: >> On Wed, Dec 9, 2020 at 1:29 PM Brandon Long wrote: >> >>> In today's much more privacy conscious world, should we have RUF reports >>> in DMARC at all? >> >> [...] >> Seems to me that's still a useful thing to have, at least sometimes. We >> might say something like: Include support for this, but don't have it on by >> default. Or even if it's an extension to DMARC and not part of the base >> protocol, it might be really helpful in some situations. Can we be explicit about that? I mean to suggest to develop but not to enable. Furthermore, I'd recommend to develop options to enable failure reports on a per-domain basis. (We could also mention that admins may contact the email in the section of troublesome aggregate reports to ask for failure reports to be enabled for their domain for the time necessary to solve the problem at hand.) > As an individual, I feel extremely strongly that failure reports should go > away in their entirety. Could we at least limit them to a single, must-be-aligned recipient? > For this ticket in particular-- the simplified failure report with only > from: and to: addresses speaks to Jesse's exact use case, without any of > the other PII that tends to get failure reports in privacy trouble (like > body content and attachments). This approach to Jesse's use case should get > a fair discussion, separate from whether we want failure reports at all. I would suggest to redact the local parts of To:, Cc: and similar fields (X-Original-To:, Received: for), possibly leaving only the From: intact. Delivered-To: should be removed. The rest of the header can be sent safely, methinks. Best Ale -- From nobody Thu Dec 10 08:18: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 65F4C3A108F for ; Thu, 10 Dec 2020 08:18:57 -0800 (PST) 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 kgAnJX3K9c7o for ; Thu, 10 Dec 2020 08:18:55 -0800 (PST) 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 90DB03A1085 for ; Thu, 10 Dec 2020 08:18:55 -0800 (PST) Received: from NAM12-BN8-obe.outbound.protection.outlook.com (mail-bn8nam12lp2169.outbound.protection.outlook.com [104.47.55.169]) by smtpauth2.wiscmail.wisc.edu (Oracle Communications Messaging Server 8.0.2.4.20190812 64bit (built Aug 12 2019)) with ESMTPS id <0QL400KMXTBHAVC0@smtpauth2.wiscmail.wisc.edu> for dmarc@ietf.org; Thu, 10 Dec 2020 10:18:53 -0600 (CST) 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.12.10.161216, AntiVirus-Engine: 5.79.0, AntiVirus-Data: 2020.11.17.5790001, SenderIP=[104.47.55.169] ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Hwr+BqEDA4qmFoDA8GPoPcTHZVA5yNhFcU94RJgRp1byPMkbV6zzOKNXOtwjYrMdSUPKSvNnqdZouPgH9bpBKu67djdh9/ReFUjr5y5E3z1HJ6EHvvKHLBs32gHNcWkFbv+HmI2k2kkKToozp9XXSMEx3dh8coHd5rqfZ9CzrquKsJLENx1t+XHQOkCjiw2vk6iUkVZ+enGvFyQAoqJjdW30cGcfC3mEiKJ9sk+bWYuVVp9ZfHD2ANTWg1agWTk7WkQYLCtw9wlCn25wV1txL2ac505Ad3l+ppvXILsBKp+ksgzA12yQvZYDT8K7nOFtuqmSPeXQfcOUdpNzHK2s2A== 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=CcjYqL+knCdg2RKS3vseollCQ9U7QNycMF67VMwnDoI=; b=fbOR3a5ZzfAVokvkI3HLsj7nY2+pLWaZ+i/F/PoIA6qbyAG33Le/YIy8djdBBt+dWufFdHeatwtowG7XTlzqfhr+T67eU9N8s2i17/lMq8cbu5dE3HMlPvpDOxybuaXZYqZaQxqL9rYpWNGI70d+DZWVmc9HMS2S/NkrFDEHDwqrjpT/9fLvMBSxJH3jguKW1KieA/iMHjgTtfKI2Of/VhUm+1Pyk0zcTymCLI97v8vlP6Evb7AOER7cvgZTv0mOxxyJrCMnoL8b6CXCeq01U8mCe1AeMc9I54PFNSzcMJ3a96iON8NH2phIH7CIgH7wru1xHJRv18wk/dcHv9co6A== 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=CcjYqL+knCdg2RKS3vseollCQ9U7QNycMF67VMwnDoI=; b=pc4cuwW1WZl9YSveUhY0v5bVX0ahigQWHU0FpeDu/Ubrfkvt/ScenK8R+iiqjnvBE0WzIwHqxnPytMhOWV3BIkU5vftB5LagC3GDYMhZ6SbqJm2N8vTnBtSFByShB16mQGAXtwKrDt3rjtFHtc9FRLwPyl3p9AHS729yNcStScA= Received: from PH0PR06MB7061.namprd06.prod.outlook.com (2603:10b6:510:21::8) by PH0PR06MB7605.namprd06.prod.outlook.com (2603:10b6:510:58::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3632.17; Thu, 10 Dec 2020 16:18:52 +0000 Received: from PH0PR06MB7061.namprd06.prod.outlook.com ([fe80::51ec:c9cd:3511:1bcc]) by PH0PR06MB7061.namprd06.prod.outlook.com ([fe80::51ec:c9cd:3511:1bcc%6]) with mapi id 15.20.3632.021; Thu, 10 Dec 2020 16:18:52 +0000 To: dmarc@ietf.org References: <609e1c9b-cc4d-d7d1-0fa8-79f515c1eee4@tana.it> <5b50a8ee-8f35-8ca1-b03d-eb4f8e697108@wisc.edu> From: Jesse Thompson Message-id: Date: Thu, 10 Dec 2020 10:18:50 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 In-reply-to: Content-type: text/plain; charset=utf-8 Content-language: en-US Content-transfer-encoding: 7bit X-Originating-IP: [47.12.96.133] X-ClientProxiedBy: CH0PR03CA0037.namprd03.prod.outlook.com (2603:10b6:610:b3::12) To PH0PR06MB7061.namprd06.prod.outlook.com (2603:10b6:510:21::8) MIME-version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [10.0.2.111] (47.12.96.133) by CH0PR03CA0037.namprd03.prod.outlook.com (2603:10b6:610:b3::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3654.12 via Frontend Transport; Thu, 10 Dec 2020 16:18:52 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: d07f43ba-95da-480e-a090-08d89d274907 X-MS-TrafficTypeDiagnostic: PH0PR06MB7605: 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: Sw+Zwzya3DScQfFGpBZrjbtTrHE8yFfH3pqIDOqiN7mQ0+9yzosGyUgFuzPSnsCv5xobOojG6bT5YdloOQVsBqB6heYu3SmkIwDFk4OzstXJhelwLG/9dCHfDn+99VEDhcn5L8BB5NNolb4Vyzk4AOgT3kcrvFDJfh/qywqeCsUGsMaRD2gFEIE27t2SCB383nEnWQYw6KuzqL1B1tFMmEnlV/khHduvz/XgwB4XerAEXbBIlxeuYS4FSP9vJTC9coHkQHH3uWp7ikdsUehZRcogIUxVAOW7m81WlCN+LmcKew4r7Jn+wHxlNvOpX8IZ3Fzte7iqfJhKMtqXelKWApp3Sh45ibtWFyCdpOnnS1acVEYCDnvma8LnHHlyGz9JPeQbCHLWROTwp0zV7yqT9/KAHXy4aKukKQnrxa+ZfuE= X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:PH0PR06MB7061.namprd06.prod.outlook.com; PTR:; CAT:NONE; SFS:(376002)(346002)(366004)(136003)(66946007)(66476007)(956004)(44832011)(2616005)(4744005)(2906002)(8676002)(5660300002)(508600001)(26005)(36756003)(6486002)(786003)(75432002)(53546011)(31686004)(83380400001)(6916009)(16526019)(86362001)(8936002)(186003)(66556008)(16576012)(31696002)(43740500002)(45980500001); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: =?utf-8?B?R0g5amF4YXZ0bkdNR2d4YUJxVlFMUjJMUTR1N0Z5Q0p0SXJVQW5GSHpsVFRq?= =?utf-8?B?bm1nNGd0NG9sWjJuOHdFTWZYcDNERUJDb3R4Q1h2VnE0OEdBdXpRVGQ0NVQy?= =?utf-8?B?VVVSOTRQUXJwaURmTExXYTQwZW1seVc0OS9yMmxZSzBBdVR6czlQclY4VmZi?= =?utf-8?B?WURJYjFEbE9USk9ITzM0NFN3Y3hFV0l4eDM5akFCT3RCVjZwYkhkL252QlAz?= =?utf-8?B?V0FIQ0x2N3lIaTJISzZwVERoekFSY1BEZXNWT3pQYUxyR3FkR0RqZkJzSTgw?= =?utf-8?B?OUFDM1hEMGhWWStOTkM5MVgrd3JnV0E1YkhjcDd6OUc5a0hqYlhyc2NMZHA0?= =?utf-8?B?M1NTYnFRU1RZMXp4MHdTSEF5U3hCODZldEs4STR6Y1owakxvbllBNSsxL0Na?= =?utf-8?B?Ym0wZTkxcW9ZWG5WRm5HREtuMXVFT0FoZEJTalZMV0dOUDNmRW5TUkZGUVdi?= =?utf-8?B?NjMxdE1aSnBpYTVRSkRJMkNnbk5udkpjOEduYlpsQ0dtLzgrQjd2RVdkbmVz?= =?utf-8?B?UitlQnhNN05aU2VvL1Y3ODRZUUkxdExIYXRTUzNEYVU1ZWdtdmQzVGlqdXQz?= =?utf-8?B?ZzFUbzBEVFFGazZlTzlsOVh3T0diSGIyUnZaRUE2bzhSeDZ6QkFjWXRXWmll?= =?utf-8?B?TzNjYU9IQStVbVIyQlE2SmFHeFQ2elBCSHE1dW5JTHQxem41dTgzeGJzSzdx?= =?utf-8?B?N2cxaEwyVmtnQ0JHam85UHBvYjdTMjljSjEvU3YwcGNBM0I1Z1dBRC9nMDhm?= =?utf-8?B?d3NheXJ0RStNamowdFhsQlk1dUtKOXNFdmY5SXozTGx5U21GNEY1SC9EQ25Y?= =?utf-8?B?Vk5yVGVUN2t2YUNaYlptZFE4aTZJdVpRRWdUUG94M3NHYisvNHc4VE9nWWNI?= =?utf-8?B?RTFKSG5qVjhJejFlRDZYYWsvKzlFTEhwNFFra3h4YVk2NmtITGdnY1JRRysv?= =?utf-8?B?bU5HOWwvT1pRV25ZdXBkbzc4d2pBdUo5VjgyWE5sVC9FRGVXbEhQZXlkRldD?= =?utf-8?B?MndXWlpma09jRnhvbkZoRTBWaDg0OWM3Q3ZlcGFTRDJqWjBtSVpyR1pLQ2hl?= =?utf-8?B?bUt2Y2thb1ZXMG56VUpQYjcwZjRnTFFaeG0yQjJVcXp0WGV5MUt5U3R2RmZ3?= =?utf-8?B?NVl5RmpEY28xL2U5dngrTlRVMGZsU2hEZzFrenBPZW5wUjlpeVh5VlJ5THMy?= =?utf-8?B?eTQ1bW54NytFU3pCbHMyVk45RHBSSGFveGVWSlgyUFNrV2RXK3ZPNmdTdGJn?= =?utf-8?B?RVNTMXVic2Z5MWl1MldtWEJpODFlem4xbk91UXFDRG1xb2pHNXR6NHBiNk45?= =?utf-8?Q?qnD1PZ4rWpVkjSqUmk+48YIH7ZnfhSLES4?= X-OriginatorOrg: wisc.edu X-MS-Exchange-CrossTenant-AuthSource: PH0PR06MB7061.namprd06.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Dec 2020 16:18:52.6481 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 2ca68321-0eda-4908-88b2-424a8cb4b0f9 X-MS-Exchange-CrossTenant-Network-Message-Id: d07f43ba-95da-480e-a090-08d89d274907 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: b9nwlkAPgXo8yue7t6j+XYhsct7Bs8QGIGiNOn9jljq31N/5/oo6bA8mJJOhJWb7pWavvS64Hv/3wtnUFtw6Jw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR06MB7605 Archived-At: Subject: Re: [dmarc-ietf] Ticket #61 - Define and add a simplified (redacted) failure report X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 10 Dec 2020 16:18:57 -0000 On 12/9/20 6:12 PM, Brandon Long wrote: > At best, we considered allowing RUF reports for cases where the dmarc domain was the receiver, ie if someone had a message that failed dmarc while sending to the same domain, then presumably the domain admin already has the power to view the message. > > But, if you limit it to that level, then the domain admin could already theoretically do this themselves by having those messages delivered to some destination to look at them, or setting > up their own forwarding rule to their dmarc analysts. I agree with this. With senders that have a relatively large volume, there is a very high probability that at least one of the recipients is local. Most of the necessary information is probably already available in logs. Jesse From nobody Thu Dec 10 09:00: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 439993A0EAF for ; Thu, 10 Dec 2020 09:00:02 -0800 (PST) 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 V8a3_TBaIgXO for ; Thu, 10 Dec 2020 09:00:00 -0800 (PST) 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 637183A0EAA for ; Thu, 10 Dec 2020 09:00:00 -0800 (PST) Received: from NAM10-DM6-obe.outbound.protection.outlook.com (mail-dm6nam10lp2104.outbound.protection.outlook.com [104.47.58.104]) by smtpauth1.wiscmail.wisc.edu (Oracle Communications Messaging Server 8.0.2.4.20190812 64bit (built Aug 12 2019)) with ESMTPS id <0QL400J72V7XB720@smtpauth1.wiscmail.wisc.edu> for dmarc@ietf.org; Thu, 10 Dec 2020 10:59:58 -0600 (CST) 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.12.10.165117, AntiVirus-Engine: 5.79.0, AntiVirus-Data: 2020.11.17.5790001, SenderIP=[104.47.58.104] ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=WArs0+QdLKm/LwilWY0lv5UPCF8SlJseV8/Nngaczm/ELkftYIJXJ63uL+pDVO5AuDJy0JihO+5FGriZgUFWOPw0yaesnmQGfCNRx6O/c78wFroJeHOS3yKDu03dNdpbUMkTa49dFi4Af8Mk6h+qEh0rihHna1ABvPnMcpHB9RfzPw37TlhBJpsW/siQ0frABYykKwragm6p7DrVHXifdQ7RNBE+k9p+I3QiQr77a1Q+YOhxKe677G6oLgdL7T5juYP6GiTJ8I3aKexfNgsMT3CZw3XSqMoJbwjqz08zFY0gSwq1pBAdFB2wI2Pc1ADGZd1WUJ37m3h4kyalmaMMaw== 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=jw4Ftbm4MpbhhW25qtsJwPqqSm54/ZJmUPc421phMDM=; b=npTTqyP5Kdu4IYmAUF96gA/4Awj2bzIsKvy2qlUD1QTi+fAYkagCXgqcAfulPZcVxABKuGKlEIwmkNm/8u5KjmrNqWGR7LoiM64jAD4l6X0Zchdp31gCXA32B2OMlO4mQAz7fWruCH0+UbUUqTrSidCgxTHJmFBrN5SV5VRN8cKtoTwGxx5K/tbI6DnLJzI290HzbXKJxjr46I4a68/sHncSWlgXN37cMpKiecgzUjxoHiPDNBZwTMM2cE8hjyKx30T085spbtFu/dfGFBA6BHnnmn0qPRATbcuv6MEM7aQAL/u7lenz8U2x/vtWg2OxDwRUXS+p5epvPgyAjExG5w== 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=jw4Ftbm4MpbhhW25qtsJwPqqSm54/ZJmUPc421phMDM=; b=nyHUNkB81BC7KtSyVWz4e30x+AhcxhaRnhqaYUGOr84rk/RZKkm0hPwZORTLwn5R1MUOj0tIqFN2HdlUxUKuaXOwVn2q/zpz2a8vGQmxv7cGfLrxoPnNgi0im3E/DJqTgc9HzIjoRt7KIFrQzssUkU4GXv9BXZKeximKFNOP5vU= Received: from PH0PR06MB7061.namprd06.prod.outlook.com (2603:10b6:510:21::8) by PH0PR06MB7413.namprd06.prod.outlook.com (2603:10b6:510:5e::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3632.19; Thu, 10 Dec 2020 16:59:57 +0000 Received: from PH0PR06MB7061.namprd06.prod.outlook.com ([fe80::51ec:c9cd:3511:1bcc]) by PH0PR06MB7061.namprd06.prod.outlook.com ([fe80::51ec:c9cd:3511:1bcc%6]) with mapi id 15.20.3632.021; Thu, 10 Dec 2020 16:59:57 +0000 To: dmarc@ietf.org References: <609e1c9b-cc4d-d7d1-0fa8-79f515c1eee4@tana.it> <20201209185246.1D40C29474C4@ary.qy> From: Jesse Thompson Message-id: Date: Thu, 10 Dec 2020 10:59:54 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 In-reply-to: Content-type: text/plain; charset=utf-8 Content-language: en-US Content-transfer-encoding: 7bit X-Originating-IP: [47.12.96.133] X-ClientProxiedBy: CH2PR18CA0009.namprd18.prod.outlook.com (2603:10b6:610:4f::19) To PH0PR06MB7061.namprd06.prod.outlook.com (2603:10b6:510:21::8) MIME-version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [10.0.2.111] (47.12.96.133) by CH2PR18CA0009.namprd18.prod.outlook.com (2603:10b6:610:4f::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3654.12 via Frontend Transport; Thu, 10 Dec 2020 16:59:56 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: fce34309-26a2-4cd6-9272-08d89d2d05ff X-MS-TrafficTypeDiagnostic: PH0PR06MB7413: 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: XIl/ExboRCmuUqwvva5PLEuRJMWPMQnIIV89nYH7NN8B6kVX16KgXRlgOFKhTZpWuJWuQRuVSPJtDCVEaRkoEZRIx+Iw03kYEA6K3n0NIz78C5k74TYI/gMEtSzpztj+/S16viMNSmL8R+yQptvUxIR5qlDy9L4ezqSyxvV797ag0Wi18Gpl6EJ8sjvQ43NgJc7/3gx8kCWwKLIrKDuYxg3FIJUIGobb8Qt6t0djC7clpQFrWbIgBK/t1PkZuvD5FWrUzPoaq2Tw5uSqjtWASVNQak2nBV2H4rqAn0ZAwunriozF+YiDc9IcKWXLFH1FzwoqhAj2RBAjZnu2GRB1jQUHEFNEmWU7DoW+CBbBoKxU2PqLs5zbEP/zoSY6Z7uVn1JXwSeOagv2PXh+lf9nZjJBCpCEK/ZpQIP4ZEuVdiASNGc7bpkuqLFXZhKG8oJXwYXcSIuqMkErJJ8YuasVIiR4N/DT7kzYByW88iGUAWo= X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:PH0PR06MB7061.namprd06.prod.outlook.com; PTR:; CAT:NONE; SFS:(136003)(346002)(376002)(366004)(2906002)(8676002)(508600001)(6916009)(66946007)(44832011)(66476007)(16526019)(31686004)(66556008)(5660300002)(86362001)(53546011)(956004)(16576012)(83380400001)(8936002)(2616005)(75432002)(26005)(31696002)(786003)(6486002)(36756003)(186003)(43740500002)(45980500001); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: =?utf-8?B?dlVaTHVuRUZNaGNUSXlZQk9tRzRVOEhnVHo4NWQ3VUNKZ3hBVVg4RGtzVDhE?= =?utf-8?B?a1lveW9ySEF0ekdabDVXSld0WXg2R1RSVzNreVNSYldxOEljTlFKbllrSy8x?= =?utf-8?B?c084eHBDOGdsM3Uxa1MyNTJFcG9OWnlGdEJrTUFqOG5STi9uNDRYUTBUeFlD?= =?utf-8?B?eXZFL0t6ZEVKc2p2bVc3WWhYRy9aeExnVjBNd3dqcC9Wa25VdS9NVkUxVnln?= =?utf-8?B?OG4yT0ViaHdXKzNQVzBZM2VBcm4ySnVoRGVFWGYyanpLeTh3Wkx5ckRQMTFW?= =?utf-8?B?aGdJTzFRc1Q3WDh2Y0lxdHJzeEEwRzFFSTJ4NmFjVWZ5UEp3Y0x5N0tnOENL?= =?utf-8?B?eFNyL3FtMTlRbGw4MzV4M00wcU40V3RDdlF3K1JqTkFHR3dGbTdqa2NiZy9l?= =?utf-8?B?a2F4NEw0WEpvVWpCNEcxeStTUEppazhnNVBBNXd0cXJzYytHekt0dEZHSW50?= =?utf-8?B?czE3TXNkYk84RXA0MGlVY1k5TUJUNXZFVnVBOVRRWU1JV2laYXREQkR0Uk42?= =?utf-8?B?RkFKL3VWR2Nxc3AvMHFTNk9uMUJDK3VzVUJXV1dYaGZuSjFIRkZBNitwdGd1?= =?utf-8?B?QTVDSWNING1xbkYrSzByUitBU2JRM056YVZqYmF5RVBEV0xqK2tnSlNZejN4?= =?utf-8?B?eUs2RGNIOEphRTdPamY5c3o5TUcvamwxRjhTL1FTUDFkR0pwUWJqcURmSW4w?= =?utf-8?B?bDZsMExuL1grU3ZIMHpqRjZsOEJRVDlIcUJOMFVvRzBxeWxkSWdPNW9VRy8v?= =?utf-8?B?V09PcWFHYkhPUmdFQmk0ZlJpNTBYT0RKVWdMemExZlJoNzBPbDhGdXZJUjNN?= =?utf-8?B?a0JZRnczYUZFeE5PSk5PUEdHdnc4eGg4ZStzbDQ2YWVjTFRnYTFuNVhVVGdI?= =?utf-8?B?eklSRXNsa3JRSnFpZ0RFdG9sRVpqVDJtYkFFUzJzK3hUWGQ1RFRnQTlBUTZn?= =?utf-8?B?VkJyNHVMcWI4NWt5dGROdWRSSVltRk8wTjlncXI5YUt3d0lkTWQ2bEpPRkUx?= =?utf-8?B?M2hna0h0YzNPR2pJaFpXTjcyQUExakRubFRmN2NsNGRHY2Rndzhudmc1elFE?= =?utf-8?B?OEZXU1I1YktLSG10N1cxOWMraUloS1orYnVBVWF6WkxQUUhtdzFsWUwwWU1T?= =?utf-8?B?TXM0L3loOThKVzhzb3QzaDBmUkJvV1ZlTHZvbURaTXRnbFRQVnV6blJOaHhP?= =?utf-8?B?V1hNVVhDQzNSMlUxaGxTM092WTZEZVd6QjZkd2h2SGRlM2JOSHgxckFuOWZM?= =?utf-8?B?Z3BqZE9pdkw0bGxOSHVNV0swQ0FzUHZNOWVyV2ZtaEM4WXhxQ2VkUm05WUw3?= =?utf-8?Q?r3mQ522pEw2DBPPbLGJbwa6/vnGZfVFloL?= X-OriginatorOrg: wisc.edu X-MS-Exchange-CrossTenant-AuthSource: PH0PR06MB7061.namprd06.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Dec 2020 16:59:57.1713 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 2ca68321-0eda-4908-88b2-424a8cb4b0f9 X-MS-Exchange-CrossTenant-Network-Message-Id: fce34309-26a2-4cd6-9272-08d89d2d05ff X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: tPmzftO4AJYDzHZ0yVwxFIVb8MBkvltViHpTQ1G1ZLGtjaWyj1U51ZPkTG4vc511JMCMMy9eK9S6slB9RcQR4A== X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR06MB7413 Archived-At: Subject: Re: [dmarc-ietf] Ticket #61 - Define and add a simplified (redacted) failure report X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 10 Dec 2020 17:00:02 -0000 On 12/9/20 10:28 PM, seth=40valimail.com@dmarc.ietf.org wrote: > As an individual, I feel extremely strongly that failure reports should go away in their entirety. Although Jesse Thompson has outlined a use case that really has no other good solution, and is equally true in other large complicated organizations. However, this problem is mitigated with a tree walk, where you can get the reports to the appropriately localized part of the organization (like, math.wisc.edu , instead of to Jesse at wisc.edu who'd need to hunt things down). To be clear, I'm not advocating for this From/To use case, but I know of universities who would. There's at least one who cleverly flattened their SPF record to include every known sender specifically because they had no mission to change the way their institution distributively sends email. That is the type of organization who *may* want From/To data, assuming they want to do more validation before adding yet another IP to their SPF. It's a stretch in my mind. I would only strongly advocate for seeing the unredacted From header, since my primary concern was with identifying a little bit more information about who was using the domain and why (i.e. who is using random ESP). The stated purpose of Failure Reports is "for quickly notifying the Domain Owners when there is an authentication failure ... also provide more information about the failed message than is available in an aggregate report". Since the focus of DMARC is to authorize the use of the domain used in the From header, then the logical next incremental levels of "more information" should be: 1) From header domain (already known) 2) local part of From address 3) Friendly From 4) Subject 5) other parts of the message containing identifiable information 1->5 decreases in usefulness/relevancy to DMARC 1->5 increases in unnecessary information disclosure Jesse From nobody Thu Dec 10 14: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 4B3743A1317 for ; Thu, 10 Dec 2020 14:58:43 -0800 (PST) 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 SW_JTZX2doXd for ; Thu, 10 Dec 2020 14:58:42 -0800 (PST) Received: from mail-pg1-x52f.google.com (mail-pg1-x52f.google.com [IPv6:2607:f8b0:4864:20::52f]) (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 12F063A1318 for ; Thu, 10 Dec 2020 14:58:42 -0800 (PST) Received: by mail-pg1-x52f.google.com with SMTP id t3so5674364pgi.11 for ; Thu, 10 Dec 2020 14:58:42 -0800 (PST) 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=AEMEHTFNbEKPZHTCOT4r38huwZLz0w9whXnPkhlQlfg=; b=Ro9VjC3R0G7Rce2Bz78b8dhEvOHPj1FmC2iWo153ouwvcEAiUP2+U4WXn64518PUVZ UqmULnkCDxNbC5gZ0ta8Grg+WF7bYQUTgowca8sAxSDBDb3DHCQrgbEWmHyD+1TjFNYM t8ccnH8Gc/uvhiD1AFLDChlgyxjGu0/I/cwkFs4MzADexmc2wkDFWW8Tb58o9ORKYvsb DI8n2ZlIdY9BBaDwx8hCggbzB+W7i+vttrEt++Fd4+s6+6IByEbhYVfcZMaD5A9uWUaD TiJuMl9XQjeW9RwRL3CjLWO2H7Loe+IyvHhID5Fo7YdOAfS8sP9B08+pMUBC60B0ISzi xGnw== 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=AEMEHTFNbEKPZHTCOT4r38huwZLz0w9whXnPkhlQlfg=; b=D4Xk1GqImW2GHyqUgaUoOl2gLZz+/3IoZJh0ILuQzxJ9u/yADhTJ0G+b5eXFnRwh6Q h6rWIJsSFWKcnktm/X5YE1jECTqGw4EdIPZpESMlpi/PqzvGwSiHWo4dMqS3xbPRNzgr qHtCdKQj5dOu9X8H354JoI9dM3WMeYSyBAvQ25aj0ChowrDg2SjHoSGotHedLy3UqL2K 779leHj6UgbvsGdnqWMzupsC8shbwpph4LdkE1e10DvqNdixwQF22C0WjE4+GaglIGXq AYqD7cEOUEbSMAZBJQqK+a8YgNOr9kSQ6gXRknGTcfus+e7vyQBbOr4/ytZUKPqgllVw 8gaA== X-Gm-Message-State: AOAM5312veb6G9nxlHepFEwklsy9lMk7X7AmjcWSixFIAF1CY+KKpuEF FMCd4ipsXlJB0ShhPL68x8tRBs2Ylko= X-Google-Smtp-Source: ABdhPJzKUix5I8uo87SoJgjkDxwNjSePuPu8A92IDSEfWBN9F7Br6N4UUV05Z5NS4kAkWkYYOmhMUQ== X-Received: by 2002:a63:4c5d:: with SMTP id m29mr8857012pgl.368.1607641121351; Thu, 10 Dec 2020 14:58:41 -0800 (PST) Received: from [192.168.0.109] (c-24-130-62-181.hsd1.ca.comcast.net. [24.130.62.181]) by smtp.gmail.com with ESMTPSA id j8sm7835069pji.1.2020.12.10.14.58.40 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 10 Dec 2020 14:58:40 -0800 (PST) To: Michael Thomas , "dmarc@ietf.org" References: From: Dave Crocker Message-ID: Date: Thu, 10 Dec 2020 14:58:39 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------CD39608859EEDF49B1FA8EE9" Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] are mailing lists worth saving? X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 10 Dec 2020 22:58:43 -0000 This is a multi-part message in MIME format. --------------CD39608859EEDF49B1FA8EE9 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 12/9/2020 3:05 PM, Michael Thomas wrote: > we know that amount of traffic going through mailing lists is tiny -- > like a couple percent. Keeping in mind that mailing lists have been a legitimate Arpanet/Internet email activity since the start of network email and that it is DMARC that created operational problems, rather than mailing list activity creating problems,  the onus for declaring a nearly 50 year activity no longer supported should be pretty compelling.  It should not rely on anecdotes or the views of an isolated few. And it certainly should not justify the change with some broad, cavalier claims about security. For starters: * Please document attacks and other misbehaviors that have been attributed to mailing list operation * Please provide objective, validated documentation for you assertion that the traffic through mailing lists is tiny. * Please include similar substantiation for the percentage claim * Please explain how this type of long-standing legitimate activity can reasonably be otherwise conducted; a generic reference to the web is not sufficient; what is needed is a point-for-point evaluation of mailing list group and technical functionality and an comparison to replacement choices. Once these documentation details have been lined up and have obtained meaningful community support, it might be worth pursuing the de-legitimization of Internet mailing lists. d/ -- Dave Crocker dcrocker@gmail.com 408.329.0791 Volunteer, Silicon Valley Chapter American Red Cross dave.crocker2@redcross.org --------------CD39608859EEDF49B1FA8EE9 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 12/9/2020 3:05 PM, Michael Thomas wrote:
we know that amount of traffic going through mailing lists is tiny -- like a couple percent.


Keeping in mind that mailing lists have been a legitimate Arpanet/Internet email activity since the start of network email and that it is DMARC that created operational problems, rather than mailing list activity creating problems,  the onus for declaring a nearly 50 year activity no longer supported should be pretty compelling.  It should not rely on anecdotes or the views of an isolated few. And it certainly should not justify the change with some broad, cavalier claims about security.

For starters: 

  • Please document attacks and other misbehaviors that have been attributed to mailing list operation
  • Please provide objective, validated documentation for you assertion that the traffic through mailing lists is tiny.
  • Please include similar substantiation for the percentage claim
  • Please explain how this type of long-standing legitimate activity can reasonably be otherwise conducted; a generic reference to the web is not sufficient; what is needed is a point-for-point evaluation of mailing list group and technical functionality and an comparison to replacement choices.

Once these documentation details have been lined up and have obtained meaningful community support, it might be worth pursuing the de-legitimization of Internet mailing lists.

d/

-- 
Dave Crocker
dcrocker@gmail.com
408.329.0791

Volunteer, Silicon Valley Chapter
American Red Cross
dave.crocker2@redcross.org
--------------CD39608859EEDF49B1FA8EE9-- From nobody Thu Dec 10 15:18: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 E716C3A132C for ; Thu, 10 Dec 2020 15:17:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.851 X-Spam-Level: X-Spam-Status: No, score=-1.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iecc.com header.b=BXf/ZNaJ; dkim=pass (2048-bit key) header.d=taugh.com header.b=V4o2jeD7 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XtrKTKhCpvZN for ; Thu, 10 Dec 2020 15:17:58 -0800 (PST) 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 E19A43A1329 for ; Thu, 10 Dec 2020 15:17:57 -0800 (PST) Received: (qmail 89255 invoked from network); 10 Dec 2020 23:17: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:mime-version:content-type:content-transfer-encoding:cleverness; s=15ca5.5fd2aca3.k2012; bh=9f1w68M0H4hBgAYnvfFNMsIsqVG1IolLWdJMPc5n4bA=; b=BXf/ZNaJlH6S45PSIGxPLwmUw7wBmxxwc6J/4IWdi5jth7mF5koRvwcTCPcJDfJXa/XTunZOAlfivSPPQ1zoS6MT/BvKavH4oadg2C+tSSscAWzUZV5LHdLn9nAklNVBD0Mud+WUjCDHDcabqncSsj8uh2IRBA2LH92v+f1/LXiqO9O4DOEmRQG87VaBPJ3Dly5oE6GAFeL9H/lrf9kwzes3m4ymaR0oI7A022hwFI9UjS1xXxI6CSswKGsJFcEKsndlTavHO+sA6fWX6lKB5PCqqo4JnFPwJ9pAeBi5/DZdHXTJVbQ+P6UENTYrHHSrHUKWLULBBaif55VgFkiMjA== DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=15ca5.5fd2aca3.k2012; bh=9f1w68M0H4hBgAYnvfFNMsIsqVG1IolLWdJMPc5n4bA=; b=V4o2jeD7/FZS1AE0CkcmIX03y0hh18sWg58GxzFSEnAijneo54ABnoKq3B8AXY26KsXiWvZZh3oA4GCNjQbRIYeL5yKmXgbLMIuzwAKeb4U/sQr8qqo2k9rOJx7zbv0Yz8NMf2qE1Xq+4/DtqB5bXRTdBkCdkyvMFr2HsaJIJEzMXUYyyOyKG+CZY8uf+gP2QNTjWytsUwq6eRGTAnRx3m5Zf4HdLinhswljpAL4c2W3iKjME2nhzM8UfTAaqeLZGC9MOSjBhkHfIov4TWEFoK1enXgbYas2A9GcXouFhcFEMUkEmJzzK0uEJh1jG4fTheJLgAyk4kkzRaapn3CO7A== 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; 10 Dec 2020 23:17:55 -0000 Received: by ary.qy (Postfix, from userid 501) id 63D2E295DCD8; Thu, 10 Dec 2020 18:17:55 -0500 (EST) Date: 10 Dec 2020 18:17:55 -0500 Message-Id: <20201210231755.63D2E295DCD8@ary.qy> From: "John Levine" To: dmarc@ietf.org Cc: dcrocker@gmail.com In-Reply-To: Organization: Taughannock Networks X-Headerized: yes Cleverness: minimal Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] are mailing lists worth saving? X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 10 Dec 2020 23:18:00 -0000 In article you write: >-=-=-=-=-=- > >On 12/9/2020 3:05 PM, Michael Thomas wrote: >> we know that amount of traffic going through mailing lists is tiny -- >> like a couple percent. People at very large mail systems tell me that while the amount of traffic from discussion lists is a tiny part of the overall mail flow, it is mail that their recipients really want and complain if they don't get. That is unlike commercial bulk mail, which recipients don't mind but wouldn't miss. The mail providers didn't invent ARC because they were bored and had too much spare time. It was because it addresses a real problem they have. R's, John From nobody Thu Dec 10 15:23: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 860663A1333 for ; Thu, 10 Dec 2020 15:23:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, 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=mtcc.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 rmFOMonclLEh for ; Thu, 10 Dec 2020 15:23:20 -0800 (PST) Received: from mail-pf1-x432.google.com (mail-pf1-x432.google.com [IPv6:2607:f8b0:4864:20::432]) (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 1B4283A1331 for ; Thu, 10 Dec 2020 15:23:20 -0800 (PST) Received: by mail-pf1-x432.google.com with SMTP id f9so5650503pfc.11 for ; Thu, 10 Dec 2020 15:23:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mtcc.com; s=fluffulence; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=u1PNKyajqifrPcG2y4hpRfwlKjXFbM1xm+uPRQxKLwM=; b=atDhsf2w0o4MfiRFmKN4ok2y39S+Fp/BQ058Ir4yldSnwCXYMMQZYWwUrhQ79A6egg kZnUZ4q3Nmq347a0Cb0MsBA/srW32Do4QU/FxVSaKe7+HO1LZ3tgtKflkNaRxHNpCRub LpcJG+bHht5w+0kjwoQS80p5r7qCsexoPCGmNBaU7O++5xZz+Ko3T6rjIB5XnxwQ9Zha dQYOwuF4eQ1zbAgatT0SFBlTZLw7XhDEI0haqSAlcFj2vLpyjcqmP6qkBV7XeOwa1oZY W1xrRgqfsdmV9tcpVHk9jU8Q5pNc5S/ygQOm8UibwBCFz9iNB1MPcAjiS6QSyDTrikjQ mPQg== 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=u1PNKyajqifrPcG2y4hpRfwlKjXFbM1xm+uPRQxKLwM=; b=S0dh1lNVnPfXnNxGCijV75kHZj/uvRacbkhGjESt4IwQr9HNhnoIyeQ7UgDevmRcpB McjVILGoBHuty7/SxRwRdclCYIQ9rg4vdGbKrUtNZg2LfwLuCp24fJt0gd3rvtywL/zZ EsyXi3aNk8X99ZMbXeanbppXBDtoi3nNPKf39W0AiyV73G/pInRK1nGU6BKE5RSpos8B VZ4nkX3oSqjfDKH7tA+YbJ10K8ZgvGJNupoE3hp+afckQF9JWGUoZUS+A7nun6M23hiK eFPAY4lQhFUEzicHVVLTwfEyEYBdM1P0AMgmT6lVutTiJqdFXuR+n7xUxaHmseylyB7l PBww== X-Gm-Message-State: AOAM533e3efXRPkeTXcdzg0T9Xtb26iWs+2h7cyBs5bo/lCEe1rWSKAV fm+/sfdvRqzB6TastkffqCKr1UZb8CepRA== X-Google-Smtp-Source: ABdhPJw7W5YV50GDIz1v+onyUMSHTA1Raw9LgqXlFjBWifyTp58nOCSdWMcrMxVYs+g6iTLnBkQuvQ== X-Received: by 2002:a17:90a:aa0f:: with SMTP id k15mr10073687pjq.171.1607642598818; Thu, 10 Dec 2020 15:23:18 -0800 (PST) Received: from mike-mac.lan (107-182-41-154.volcanocom.com. [107.182.41.154]) by smtp.gmail.com with ESMTPSA id s65sm7117906pgb.78.2020.12.10.15.23.17 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 10 Dec 2020 15:23:18 -0800 (PST) To: Dave Crocker , "dmarc@ietf.org" References: From: Michael Thomas Message-ID: <9d7e7d03-f8e9-7891-0d74-c50dfd2ac274@mtcc.com> Date: Thu, 10 Dec 2020 15:23:16 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------59AA7A04E8DD4FB01C93AF00" Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] are mailing lists worth saving? X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 10 Dec 2020 23:23:22 -0000 This is a multi-part message in MIME format. --------------59AA7A04E8DD4FB01C93AF00 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 12/10/20 2:58 PM, Dave Crocker wrote: > On 12/9/2020 3:05 PM, Michael Thomas wrote: >> we know that amount of traffic going through mailing lists is tiny -- >> like a couple percent. > > > Keeping in mind that mailing lists have been a legitimate > Arpanet/Internet email activity since the start of network email and > that it is DMARC that created operational problems, rather than > mailing list activity creating problems,  the onus for declaring a > nearly 50 year activity no longer supported should be pretty > compelling.  It should not rely on anecdotes or the views of an > isolated few. And it certainly should not justify the change with some > broad, cavalier claims about security. > > For starters: > > * Please document attacks and other misbehaviors that have been > attributed to mailing list operation > * Please provide objective, validated documentation for you > assertion that the traffic through mailing lists is tiny. > * Please include similar substantiation for the percentage claim > * Please explain how this type of long-standing legitimate activity > can reasonably be otherwise conducted; a generic reference to the > web is not sufficient; what is needed is a point-for-point > evaluation of mailing list group and technical functionality and > an comparison to replacement choices. > > This assumes that the IETF has any say whatsoever in this matter. It doesn't. DMARC and ADSP before it gives the world the ability to say "i don't care about mailing lists". Apparently Yahoo is one of them. That horse has left the barn. Many domains would rather the security improvements with p=reject. And it's not mailing lists that are the problem per se, it is that the security posture that facilitating them leaves organizations vulnerable to phishing attacks. Many organizations are giving that a nope, and there is nothing we can do about that. There are many things that had their day and died because they couldn't adapt, were redundant, or their time was just over. Usenet is a great example. After 16 years of trying to deal with the mailing list problem, we're right back where we started. Murray's hacks for recovering the signature are not different in kind to my heuristics and hacks I did 15 years ago. And ARC seems to boil down to requiring the previously unsolved problem of "trusting" the mailing list. So no, I won't be doing any of those things because they are completely beside the point. Feel free trying your hand solving it. Mike --------------59AA7A04E8DD4FB01C93AF00 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit


On 12/10/20 2:58 PM, Dave Crocker wrote:
On 12/9/2020 3:05 PM, Michael Thomas wrote:
we know that amount of traffic going through mailing lists is tiny -- like a couple percent.


Keeping in mind that mailing lists have been a legitimate Arpanet/Internet email activity since the start of network email and that it is DMARC that created operational problems, rather than mailing list activity creating problems,  the onus for declaring a nearly 50 year activity no longer supported should be pretty compelling.  It should not rely on anecdotes or the views of an isolated few. And it certainly should not justify the change with some broad, cavalier claims about security.

For starters: 

  • Please document attacks and other misbehaviors that have been attributed to mailing list operation
  • Please provide objective, validated documentation for you assertion that the traffic through mailing lists is tiny.
  • Please include similar substantiation for the percentage claim
  • Please explain how this type of long-standing legitimate activity can reasonably be otherwise conducted; a generic reference to the web is not sufficient; what is needed is a point-for-point evaluation of mailing list group and technical functionality and an comparison to replacement choices.

This assumes that the IETF has any say whatsoever in this matter. It doesn't. DMARC and ADSP before it gives the world the ability to say "i don't care about mailing lists". Apparently Yahoo is one of them. That horse has left the barn. Many domains would rather the security improvements with p=reject. And it's not mailing lists that are the problem per se, it is that the security posture that facilitating them leaves organizations vulnerable to phishing attacks. Many organizations are giving that a nope, and there is nothing we can do about that.

There are many things that had their day and died because they couldn't adapt, were redundant, or their time was just over. Usenet is a great example. After 16 years of trying to deal with the mailing list problem, we're right back where we started. Murray's hacks for recovering the signature are not different in kind to my heuristics and hacks I did 15 years ago. And ARC seems to boil down to requiring the previously unsolved problem of "trusting" the mailing list.

So no, I won't be doing any of those things because they are completely beside the point. Feel free trying your hand solving it.

Mike

--------------59AA7A04E8DD4FB01C93AF00-- From nobody Thu Dec 10 15:23: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 90ED63A134E for ; Thu, 10 Dec 2020 15:23:24 -0800 (PST) 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 plkTSKaTKi-6 for ; Thu, 10 Dec 2020 15:23:23 -0800 (PST) Received: from mail-pg1-x535.google.com (mail-pg1-x535.google.com [IPv6:2607:f8b0:4864:20::535]) (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 22CF03A1335 for ; Thu, 10 Dec 2020 15:23:23 -0800 (PST) Received: by mail-pg1-x535.google.com with SMTP id w5so4988805pgj.3 for ; Thu, 10 Dec 2020 15:23:23 -0800 (PST) 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=C/2+p8KXeNbINPHeYbDXB6E7dwUVwnrA85p8rC3KyF8=; b=usplYoY0sNQHiik5niS5OhgWLL0/yUVNYlWuIVN9/tRdEa7L0V8V12L5Ot7uFqOCa2 fgo3/+uGz6CR9l0NYZqbOdc1xRJbP5VZ/hmcYCkCNdZZpqE/KIj2CBTFCCPsINLd1n1b AL4W0grW4LtOtGG7/QxcUK3jj0UEg5hmq71bHAsGYMZRL/9Td2KajiDw5RXG5YyUQFnF hrXH8hnO5OKNUj4Li/DqHnqPmM0IvGqFT77rZX/lH3szdduV/VyuFy7kxgdhC4kIAqy3 r9A3Mji86YS9Zw5AUadGYRqXkkO2uldFG/pQUPJc9A6lpvEdG/93ZfTg7i7ggk2dYI9d 1pDg== 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=C/2+p8KXeNbINPHeYbDXB6E7dwUVwnrA85p8rC3KyF8=; b=tDzCuHAXEd1TTxiGfOkQM/Wp8YtSmf9r6ljoDWh5sTTpfhvmhqwd31DFpzzC2QAd/L t0QE7bNDDZNf3wDASfhkXz0QGH9rpD8OVJ9011q+2fHIgSPDSRbodp4p/1P6Mj8MkiNb t5WEiXZKh7h1ftt1vFV/eS9aZU0pLlRJp6mV+2NNo6CjFby0Ylnyv9bXcpK5VmhlvH6U 0rifNHDOH4IeJsmQDNgISyocoumTYIXr4cCCy70VUwzOAGJ/ZhcjJfeILLlF2SD/K5pd 5QgMpZ0IBpId8PCmOBfJEG0Z67wqcd6bjEchCdRSeEWBfT3IRmP1YP09EhwTWL7YgGNm Vbeg== X-Gm-Message-State: AOAM530KBs9/6eBBpjjr7w/Ri0YUh0/vPnwc71aTiINJKHd/ABW38bTJ o1D07oB+CPMVW7apyek0DNIHbtrT7lI= X-Google-Smtp-Source: ABdhPJyCvbnSZgNL2owhe6QVLkONfXvb4473sq9AkGlwh7WWWajWCvD0xZRpWK0mHLKK8E1NhEGXPw== X-Received: by 2002:a62:2f43:0:b029:199:d09a:363 with SMTP id v64-20020a622f430000b0290199d09a0363mr8624565pfv.58.1607642602286; Thu, 10 Dec 2020 15:23:22 -0800 (PST) Received: from [192.168.0.109] (c-24-130-62-181.hsd1.ca.comcast.net. [24.130.62.181]) by smtp.gmail.com with ESMTPSA id z7sm7724773pfq.193.2020.12.10.15.23.21 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 10 Dec 2020 15:23:21 -0800 (PST) To: John Levine , dmarc@ietf.org References: <20201210231755.63D2E295DCD8@ary.qy> From: Dave Crocker Message-ID: Date: Thu, 10 Dec 2020 15:23:21 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.5.1 MIME-Version: 1.0 In-Reply-To: <20201210231755.63D2E295DCD8@ary.qy> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] are mailing lists worth saving? X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 10 Dec 2020 23:23:29 -0000 On 12/10/2020 3:17 PM, John Levine wrote: > People at very large mail systems tell me that while the amount of > traffic from discussion lists is a tiny part of the overall mail flow, > it is mail that their recipients really want and complain if they > don't get. The relates to my point about getting community consensus... d/ -- Dave Crocker dcrocker@gmail.com 408.329.0791 Volunteer, Silicon Valley Chapter American Red Cross dave.crocker2@redcross.org From nobody Thu Dec 10 15:25: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 594F93A1333 for ; Thu, 10 Dec 2020 15:25:50 -0800 (PST) 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 LycYbIet2QPN for ; Thu, 10 Dec 2020 15:25:49 -0800 (PST) Received: from mail-pg1-x52f.google.com (mail-pg1-x52f.google.com [IPv6:2607:f8b0:4864:20::52f]) (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 299F03A1336 for ; Thu, 10 Dec 2020 15:25:49 -0800 (PST) Received: by mail-pg1-x52f.google.com with SMTP id w5so4994830pgj.3 for ; Thu, 10 Dec 2020 15:25:49 -0800 (PST) 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=sXOdXzPbbNiPy0iYkSWrPpKFTj9HwdUUD6D61mZW72o=; b=NRQbgeQLYKDh0ZG8bSZCMnvCEmGYIGB9G8yDnojnwWFkuZ/85HUusoe0WHhvyRjWmy 7qyrdU+n9NnuxDf8Ts4UYFkwbdcd/8MGc8eSTvIZKpCsVnZBpwf5CpPcqR84DODGky+H xluxIyFyD6J3y3+6UaIrB/M1/HoaZoRzowaDBXYt3xWTosWDJPJOd7ZMlmx0xqulqyk+ kgK0ietj6vZ6Lv7nPsL1iOSJ8MOnBvfDDFmpbD3sRX222CDyLct+p9Bqy32BeFkVroxb h+CpfzHvP7omXuEuv6eBgjUjCDiQh9lHB2WZzHjKh4QIC3qWGbmk8ESMJvvVqkl2oID0 cQIA== 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=sXOdXzPbbNiPy0iYkSWrPpKFTj9HwdUUD6D61mZW72o=; b=AbAJvWRWrCk7bZhCJwT4kclZGWmQu9lHQRQ2RxMKoICjpw1UAKmtbbADcykXs3grcj VH0wNJYytjNi2oUKCYWRWvorxZjRmGoN3u/9KgbQX8inaMlj1ofhCxT6os0txmczqmRh XHXtkH9K9bcT6PZYV+ANQHyqcbN+2f4JBjDkzx9liurZ1MPAGvtE50UPhRt9A4TQDav6 BhNrkM0UWGDmJTKLuxbZ4BL94wwrgHc/XJ1gn/Jk3BLzP27jgOcRoRR/UfEBFnn6OIg9 F+7J4jWZSqThdvcNy4sRKK6GcKC7gtdexFBbZXbWdPgV2Se35TzqOebsnzZw9OysDF3Q gmIA== X-Gm-Message-State: AOAM532L5qKFzvzNjseDhXEGu9xXxLLDTCUOSY9i17uy22iRDJC8WgPn OU8Z7UWDWmGl4RziYAxfMRgCo8wA8Po= X-Google-Smtp-Source: ABdhPJyI9f36xf+w8EFbuX6V39Nm0/HVuhrMCkgfNRdaZFS3kRgH56sdBq+HmI8aGqpXRB/linaRsg== X-Received: by 2002:a17:90b:2355:: with SMTP id ms21mr10063641pjb.125.1607642748465; Thu, 10 Dec 2020 15:25:48 -0800 (PST) Received: from [192.168.0.109] (c-24-130-62-181.hsd1.ca.comcast.net. [24.130.62.181]) by smtp.gmail.com with ESMTPSA id a23sm7737006pju.31.2020.12.10.15.25.47 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 10 Dec 2020 15:25:47 -0800 (PST) To: Michael Thomas , "dmarc@ietf.org" References: <9d7e7d03-f8e9-7891-0d74-c50dfd2ac274@mtcc.com> From: Dave Crocker Message-ID: Date: Thu, 10 Dec 2020 15:25:46 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.5.1 MIME-Version: 1.0 In-Reply-To: <9d7e7d03-f8e9-7891-0d74-c50dfd2ac274@mtcc.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] are mailing lists worth saving? X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 10 Dec 2020 23:25:50 -0000 On 12/10/2020 3:23 PM, Michael Thomas wrote: > So no, I won't be doing any of those things because they are > completely beside the point. Feel free trying your hand solving it. Yet you were the one making the proposal and making claims as foundational to it. d/ -- Dave Crocker dcrocker@gmail.com 408.329.0791 Volunteer, Silicon Valley Chapter American Red Cross dave.crocker2@redcross.org From nobody Thu Dec 10 15:26: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 228E63A1336 for ; Thu, 10 Dec 2020 15:26:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.751 X-Spam-Level: X-Spam-Status: No, score=-1.751 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, 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=mtcc.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 RFtgDMkmmSRJ for ; Thu, 10 Dec 2020 15:26:41 -0800 (PST) Received: from mail-pg1-x52f.google.com (mail-pg1-x52f.google.com [IPv6:2607:f8b0:4864:20::52f]) (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 1DA413A12E1 for ; Thu, 10 Dec 2020 15:26:41 -0800 (PST) Received: by mail-pg1-x52f.google.com with SMTP id t37so5763208pga.7 for ; Thu, 10 Dec 2020 15:26:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mtcc.com; s=fluffulence; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=Blv/47SPuJ1haLkL9IHcmBSQn+FzOIUGq8ou3u+YeLo=; b=Zw/9C7KkcWAzKaCe88/KphehHlf6PL2S/475vQUkc2PvbTfLW+4FT9cadgbuqQvZa5 H2Tzi3vr1pyzz6DmCWY37RvMgaF3ne0VUZNSHDiDzrAJA6j9v1lot/sb4ScQGLF6M8B6 LZZjvqC6VQhRK2RAvA1z8Cy/NmnezqxEpghbr0pbTUl6Ti4yoaoVY99rwHb9xwyTQx1m ft2dRfIN5sa6mW/ldIzTgH9cLLt2tgjrlNo2soyIOvkFKXKSdeLBhEkm2oKp/MbcW9Kx jzA6VVFTQJPRgexX1K2DCLxzdOCkn4iFEJwHYD1h8DX4ntiBY7Pcp2lmxrx1mqzIY+D0 YPiQ== 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=Blv/47SPuJ1haLkL9IHcmBSQn+FzOIUGq8ou3u+YeLo=; b=XESHvm/TsHeC++Jsf/oNrqsgwj4eHvqcrrv9UfDZNiEdnjel71Vc4mVCetJjxUFqPc cMJQj3H5RfUVN2vKsO0AAaVWFb+S4P8VvG/NFZhhu+24DIp1OsyyElVCPVQ7OJOK4RYU 58O8ut23/oV8Iip7iLeChbYJ3IwY92ryn6Li1QLkOrpuJRElmfzM0ZLNf6P+KullsJap 2kSFRBbAq+H0omhKUhQGcMv1HMcvvWiCk7HNDpgq4jdZiT03FNbiLbyj/vdtnzlBBmoc 5YNuJqpI/pxZonVf81rjW69/40AW5WoMZP+TTunCBLFcMU8d2hIxdnuIFw2LWaYwrRpO 5C5A== X-Gm-Message-State: AOAM531MukNFJAIDnNkLScTiM3J11S/rL4nMY2kvzNadMNIS9LFxUPd7 v4CrNI6Yn5aFjewVhbbbhVZDWGED8ma8wA== X-Google-Smtp-Source: ABdhPJzWR2+iN8GdkcQ2y5Hl4al5dLWsZR67tTJFEcF6gYp3hq6ue2qTUcibhy5ywTHfAETKef2cmw== X-Received: by 2002:a63:f02:: with SMTP id e2mr8736368pgl.148.1607642800338; Thu, 10 Dec 2020 15:26:40 -0800 (PST) Received: from mike-mac.lan (107-182-41-154.volcanocom.com. [107.182.41.154]) by smtp.gmail.com with ESMTPSA id q16sm7864896pfg.139.2020.12.10.15.26.39 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 10 Dec 2020 15:26:39 -0800 (PST) To: dmarc@ietf.org References: <20201210231755.63D2E295DCD8@ary.qy> From: Michael Thomas Message-ID: Date: Thu, 10 Dec 2020 15:26:38 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.5.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] are mailing lists worth saving? X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 10 Dec 2020 23:26:42 -0000 On 12/10/20 3:23 PM, Dave Crocker wrote: > On 12/10/2020 3:17 PM, John Levine wrote: >> People at very large mail systems tell me that while the amount of >> traffic from discussion lists is a tiny part of the overall mail flow, >> it is mail that their recipients really want and complain if they >> don't get. > > The relates to my point about getting community consensus... > There is no consensus to be had. IETF has no say in this matter. Reddit is a terrible Usenet 2.0, but that's what happened when Usenet couldn't keep up with the times. Mike From nobody Thu Dec 10 15:34: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 1CB273A134D for ; Thu, 10 Dec 2020 15:34:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.751 X-Spam-Level: X-Spam-Status: No, score=-1.751 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, 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=mtcc.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 XvYEuw6-_QC4 for ; Thu, 10 Dec 2020 15:34:41 -0800 (PST) Received: from mail-pg1-x532.google.com (mail-pg1-x532.google.com [IPv6:2607:f8b0:4864:20::532]) (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 92D763A134C for ; Thu, 10 Dec 2020 15:34:41 -0800 (PST) Received: by mail-pg1-x532.google.com with SMTP id t3so5768871pgi.11 for ; Thu, 10 Dec 2020 15:34:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mtcc.com; s=fluffulence; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=VT4hOD87Pe9X/v3vkTHVd2rx6QLaDKHzONuNOmnEetY=; b=ffvet3++2tGkm/hJzh0RxojfHGQnsg2oTHx6Fk6yMnqDMWflh1pT3vxvqm0Ne33+BO fWZptPWG6OtFayshW3Y7TdAgmoP1R0ThwIcPjg2/QHlcsxl6XNPfWt1ff6mkw3xHS7dk M0KLQKUnR+Fm9I/AdKBI5tp7uFiOdKjUkYMac3aJSvdEoZec5cFUKEVzL+vDEgp9vTIr fWq6ODuan3NPOWwIbyi8FqcymnwvfEbYrMWWsG8vviocM2kshGm9V3gYBXSVVbpsEMUc jiqKkXRS/Om0ufViow53eaylI2RK0eaArotGsgEoO9aBgs5O3gh93Fx17dnfwN0KkxrR Hr8Q== 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=VT4hOD87Pe9X/v3vkTHVd2rx6QLaDKHzONuNOmnEetY=; b=nSAobKOArPBS/YXUQct5NsVX2Mn97WpV/eB9xlRv5e08zf5FaWkgjenZeZYH51DhhK QphCwaie868kQZH/fH+oMDckKYJUSqgs4yIojSEXBUXLvTsmHDt9tywyk3mOufprtvcx THXgux6F3BIx0BNm+IhwAsCzck0EAXsk2mEwbNl0KVZIfw64CsKzLQQmarMIJwPhQA1D 31SphUDijAbPiPXvHv6FGDJSR/WZWfgZrGTYy43uAtfab8wsvWovhJOjoR34IFMnX9z7 cWQjcPpgPXFxi5GPFrkdyL/aaTWapQ/Zb7Sa+NMDsO1lJhuj842RIPpMZdBJpkGsrc12 V+wQ== X-Gm-Message-State: AOAM5333IldElo5Ni5YBLomzqYp2G6Ht8/rNGm8bA9qqGcnC6xkgAsWx gWT1TZwvaU82hKRfaNskLt3hq48a1wmV+w== X-Google-Smtp-Source: ABdhPJwfRAPTjzwTQQus4vKgZvMmIbO5TH8JZZZN8KxOQAXRXgMl3cniCMmjm6s4SDO0Ll4SQ0QKKw== X-Received: by 2002:a65:4187:: with SMTP id a7mr8844875pgq.16.1607643280781; Thu, 10 Dec 2020 15:34:40 -0800 (PST) Received: from mike-mac.lan (107-182-41-154.volcanocom.com. [107.182.41.154]) by smtp.gmail.com with ESMTPSA id o11sm7632090pjs.36.2020.12.10.15.34.39 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 10 Dec 2020 15:34:40 -0800 (PST) To: Dave Crocker , "dmarc@ietf.org" References: <9d7e7d03-f8e9-7891-0d74-c50dfd2ac274@mtcc.com> From: Michael Thomas Message-ID: <670e48f5-cb86-0a40-5c9a-712879323db8@mtcc.com> Date: Thu, 10 Dec 2020 15:34:38 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.5.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] are mailing lists worth saving? X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 10 Dec 2020 23:34:43 -0000 On 12/10/20 3:25 PM, Dave Crocker wrote: > On 12/10/2020 3:23 PM, Michael Thomas wrote: >> So no, I won't be doing any of those things because they are >> completely beside the point. Feel free trying your hand solving it. > > Yet you were the one making the proposal and making claims as > foundational to it. > I don't need to prove anything here. I'm just making the observation that after 15 years we still don't know how to solve the mailing list problem so I'm going to assume that we never will. We don't even know how to declare victory. Every time I've asked that it's met with "good question".  Ditto the mailing list trust problem. Mike From nobody Thu Dec 10 15:45:07 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19B3A3A134D for ; Thu, 10 Dec 2020 15:45:05 -0800 (PST) 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 V41Hr0wkM3Uh for ; Thu, 10 Dec 2020 15:45:04 -0800 (PST) Received: from mail-pg1-x52a.google.com (mail-pg1-x52a.google.com [IPv6:2607:f8b0:4864:20::52a]) (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 03D1A3A134C for ; Thu, 10 Dec 2020 15:45:03 -0800 (PST) Received: by mail-pg1-x52a.google.com with SMTP id o4so5833893pgj.0 for ; Thu, 10 Dec 2020 15:45:03 -0800 (PST) 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=cC3W2fpAImRbi7gNXH7DpI2hbdu4CMIFHqloM+UG2+4=; b=u4L0Hi+w8tUH7qLQLnji1Ya23v5qZ0RDVuECs+Rc9DbMvIMyFN2I5YEPWN3RY//UoV 0MtQH0SsLe1AghaUA49uhQ5/ulugCqvXd1WZeTB2Ljzp/Qbw4LPcP31N7N0i5XqsB6le tMgqMw2JpcrGN5OCXwu4kLK8MNWLSgxT9gBobdNRbqrOXjgTUQrKFWOVpCgEUqiPSnmQ icGJKStGrYSeJloJ/q6IfJzdwkSefp2+p8ysjzb4mFfF69RjN5w2xHjDr8CvL8Rz+1G2 GpMGg8DEwFD9GJX79pgyNp4J3JTbeg1l+3Y3cQMMBeXRuQKPVjnjIeoN2vcSLWlCDEa6 m9jw== 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=cC3W2fpAImRbi7gNXH7DpI2hbdu4CMIFHqloM+UG2+4=; b=ife2sI8xCPcFPsPZofxxEmXNz4oCLFBVS6GDGkkOAq+NS8rLg1hzretUZRhfWoX9uT X/P0VgsAUkl3/6dnBdhel8HxWM0euALqfd8HuYiW/mJqATk5pn+Hx0peZ3dtV8HLquOQ 439OIHYIqO0Rw2Dog4gXm6hXRi6Z2g6Obnsbuv7DIMIJCsxGuL+SHWp/YQTTC+/BgIqX 5FHfX/YB020H/XztPtpv6FbtV125jeuTx/d0oKf2+yibygQ8KkLYpyYFAyigvG6zA8gJ nEuRVU4NIhrFUV3qRb82L3ZG1UEA6CGwsrz7JiKKm1zvXHaQNBXPWdmCiKDwrQhv0yls BAtQ== X-Gm-Message-State: AOAM532UuL4KEBTmUZwnFJ75CQ7avn8o3BwxNEmKcWlq5e8WY5YRl2O+ gF+F04p9LMbM3OcNmwUKH1T2uhTz0Ow= X-Google-Smtp-Source: ABdhPJw4RLfRxCwPgaEAprqLJkjgueJ7MY+dfI/JflUqV0fDwsjt6xGdHwrxbboMZ+toUNeFQ/GjUQ== X-Received: by 2002:a17:90a:7d08:: with SMTP id g8mr10153715pjl.180.1607643903199; Thu, 10 Dec 2020 15:45:03 -0800 (PST) Received: from [192.168.0.109] (c-24-130-62-181.hsd1.ca.comcast.net. [24.130.62.181]) by smtp.gmail.com with ESMTPSA id x10sm7372783pga.70.2020.12.10.15.45.02 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 10 Dec 2020 15:45:02 -0800 (PST) To: Michael Thomas , "dmarc@ietf.org" References: <9d7e7d03-f8e9-7891-0d74-c50dfd2ac274@mtcc.com> <670e48f5-cb86-0a40-5c9a-712879323db8@mtcc.com> From: Dave Crocker Message-ID: <1b4a2d04-affa-2162-7dbb-fde99d0e8288@gmail.com> Date: Thu, 10 Dec 2020 15:45:01 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.5.1 MIME-Version: 1.0 In-Reply-To: <670e48f5-cb86-0a40-5c9a-712879323db8@mtcc.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] are mailing lists worth saving? X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 10 Dec 2020 23:45:05 -0000 On 12/10/2020 3:34 PM, Michael Thomas wrote: > I'm just making the observation "Basically just declare" is not a linguistic form for 'just making an observation'.  It's a proposal. d/ -- Dave Crocker dcrocker@gmail.com 408.329.0791 Volunteer, Silicon Valley Chapter American Red Cross dave.crocker2@redcross.org From nobody Thu Dec 10 15:53: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 CACFE3A1357 for ; Thu, 10 Dec 2020 15:53:09 -0800 (PST) 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 HsHxF9QBtnaC for ; Thu, 10 Dec 2020 15:53:08 -0800 (PST) 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 35EBD3A1354 for ; Thu, 10 Dec 2020 15:53:08 -0800 (PST) Received: by mail-vs1-xe2d.google.com with SMTP id r24so3851071vsg.10 for ; Thu, 10 Dec 2020 15:53:08 -0800 (PST) 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=fnkpMaR+v3mDn2JpJj/TTNnR1QcUO2JANxypuHKoVKA=; b=YETSmz3VrkW0dXz9v+tEvZhYWy5YFCb8cSKfWPwfGMwzogtio2W6Usn9+eSqD0GUac oB4tOc8ckRVgrPRONXJ6xriwEmaURkh+xF/UQ5NmGSAmRtRiVBOubT53PsgKs2ofHrva BGy2hMJU0WLgPnMldstt8gIwccTp6GjugYOR+b4u80kCS/JJ7TagnLO0o/IfhMn11Myn inL4/z3URbvwvnQcrimY1FugNXQGwXwc10nL3MRPG3QzhP7yej8vGY/QVRgVbfPCo/27 BcnjPS8Egoc/6RmSYA83AG0fsJRwGKk9eh8k5AkMf9QaOzx+GLa+bUmZRm6ahQqrY0cq GliA== 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=fnkpMaR+v3mDn2JpJj/TTNnR1QcUO2JANxypuHKoVKA=; b=T0lyKJx2f75G7JcVGcuaJIQ1J0ghvmehgcXUrC74b3qb1eRRv0XuxYqEm+VH3qbrSf OfJsTzoyP5IQJeToVzWxHP9Boh42ApUorNkuJ1bO+akmNSo3aUDFJm/YDa7zxPbNPZ51 ZlDQzdh8qtldJmyKCql3NEY1LGNNcRabSVx38/6bcM6XO+EsTVRq9VDR+XbkEfMGYhq/ XkS/TaGwYKi5ZP3XHcj8T9U0ZGsoLwt2UAHRsO4ZDQkh4qQPaRMLJGgHslMbcSUcaOCc zQbE2jJVqJIESWr/OClZm6r4rF2B1BZ8Cbo1fnggQ4VNUuQQ9YIldILMrALuy+dm5G8u 6sFQ== X-Gm-Message-State: AOAM533YWMQhUWLG3hVmEQeAUCWacSkhLNbDn7THf/Tq/tTvx3gzK9CH gWMk6niP4Y16eAvPUJgGvnSrKwUZ96iXcT37FgrBxg== X-Google-Smtp-Source: ABdhPJy4pOQQAWDtoboE/xPwUb+6dlXKgk2cMS24cZQ6uFCJUhKRi199EdlZy67zTdNEII1EFzki9OrADj/JJ8NO9uc= X-Received: by 2002:a67:efd9:: with SMTP id s25mr10854512vsp.56.1607644387152; Thu, 10 Dec 2020 15:53:07 -0800 (PST) MIME-Version: 1.0 References: <9d7e7d03-f8e9-7891-0d74-c50dfd2ac274@mtcc.com> <670e48f5-cb86-0a40-5c9a-712879323db8@mtcc.com> <1b4a2d04-affa-2162-7dbb-fde99d0e8288@gmail.com> In-Reply-To: <1b4a2d04-affa-2162-7dbb-fde99d0e8288@gmail.com> From: Seth Blank Date: Thu, 10 Dec 2020 15:52:56 -0800 Message-ID: To: Dave Crocker Cc: Michael Thomas , "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="0000000000009f2bf805b624e00a" Archived-At: Subject: Re: [dmarc-ietf] are mailing lists worth saving? X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 10 Dec 2020 23:53:10 -0000 --0000000000009f2bf805b624e00a Content-Type: text/plain; charset="UTF-8" Michael, Dave, this discussion is off topic. Please see the Chairs' note here: https://mailarchive.ietf.org/arch/msg/dmarc/HhfoBzu_RlM4aiMbiLc4BaHjjmc/ There will be a time to discuss indirect mail flow (and if we even care about mailing lists) after the core bis tickets are addressed. Thank you. Seth, as Chair On Thu, Dec 10, 2020 at 3:45 PM Dave Crocker wrote: > On 12/10/2020 3:34 PM, Michael Thomas wrote: > > I'm just making the observation > > > "Basically just declare" is not a linguistic form for 'just making an > observation'. It's a proposal. > > d/ > > -- > Dave Crocker > dcrocker@gmail.com > 408.329.0791 > > Volunteer, Silicon Valley Chapter > American Red Cross > dave.crocker2@redcross.org > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > -- *Seth Blank* | VP, Standards and New Technologies *e:* seth@valimail.com *p:* 415.273.8818 This email and all data transmitted with it contains confidential and/or proprietary information intended solely for the use of individual(s) authorized to receive it. If you are not an intended and authorized recipient you are hereby notified of any use, disclosure, copying or distribution of the information included in this transmission is prohibited and may be unlawful. Please immediately notify the sender by replying to this email and then delete it from your system. --0000000000009f2bf805b624e00a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Michael, Dave, this discussion is off topic.


<= /div>
There will be a time to discuss indirect mail flow (and if we eve= n care about mailing lists) after the core bis tickets are addressed.
=

Thank you.

Seth, as Chair

On Thu, Dec 10, 2020 at 3:45 PM Dave Crocker <dcrocker@gmail.com> wrote:
On 12/10/2020 3:34 PM, Michael Thomas wrot= e:
> I'm just making the observation


"Basically just declare" is not a linguistic form for 'just m= aking an
observation'.=C2=A0 It's a proposal.

d/

--
Dave Crocker
dcrocker@gmail.com<= /a>
408.329.0791

Volunteer, Silicon Valley Chapter
American Red Cross
dave.crocke= r2@redcross.org

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


--

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


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

--0000000000009f2bf805b624e00a-- From nobody Thu Dec 10 15:56: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 DBF013A1358 for ; Thu, 10 Dec 2020 15:56:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.751 X-Spam-Level: X-Spam-Status: No, score=-1.751 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, 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=mtcc.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 RIYLyL8oV8BY for ; Thu, 10 Dec 2020 15:56:19 -0800 (PST) Received: from mail-pf1-x42a.google.com (mail-pf1-x42a.google.com [IPv6:2607:f8b0:4864:20::42a]) (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 8F4EE3A1357 for ; Thu, 10 Dec 2020 15:56:19 -0800 (PST) Received: by mail-pf1-x42a.google.com with SMTP id i3so5743968pfd.6 for ; Thu, 10 Dec 2020 15:56:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mtcc.com; s=fluffulence; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=PtMkmUNbw0b9rJtPwiwmiQHjDuMefohV0B1ACg0v2DY=; b=PX8DpQCNALDHMnTpc3Mj0RVv3N83Jr5ZBUDAI2PgQmajWuTuo0EtdVGTrsdocrGbJL q9ncnUX0oRtPcVPqyojPY6NjnKY+wVQpO7q71wfTnEWmGNU4JCk9YMeqtXO5AJgXjIh1 EbERnJpfhVxoWJ9J+7twOkTcKu5Zgt4Erg8zIgIB1rfZ+DLPhzW39oU6jU3poIipNeT6 HQFU07jPRny76/XxBh4v3IqMSBA4p4DyrrfzoID1EO6XU6bklbhTaGO77trOXjNewD5U iwyqsXj4z31wjVwhKFjheMbB5AevOHbgDBT3ewJ+RxMphWE/veQk4XH6bo34+iMJlEwq FTCw== 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=PtMkmUNbw0b9rJtPwiwmiQHjDuMefohV0B1ACg0v2DY=; b=AvIhHdQRHGXPmLnIHwyNZQ98gTQ3O3ApHmF5f3Vyxp9ZapBwoBTqgjOQDxS2inO39g Nv5vJB5rsk5qCq/2DIhyja9IBLVAbgpuV1wE+vdiW5mbRUwasBjI8qnT1i5UeOWnFBoE ihMEf6XKj5dr3eEJGdJpKtbY2pM5hx1UGx3FDQa+fOG/yjaouadkiuEnxXW9+Q6yhu0j 2wAHejuLSFGXeCRDUWGk4ecg/69rOXLzRQFI+GZaqeHf3OXXlxhjiRF9Ft6S5NuOBdcZ HSZ0yhrbFoHGK4nEN9VnOYp+HytG2+PzDhUNFCqGvtJKV26tBAaRi35YN7ehHUPlq8ZR GAdw== X-Gm-Message-State: AOAM532jWpdszJ0q9amf3YQgWa0aRkSqOm9dATEiFa6mjMZQ3uHlKh93 KnWnDS3LLWAvDqw0JuCZK4tWJvggq85SIg== X-Google-Smtp-Source: ABdhPJz8ae+Zgd+UMKAtqnGZTx4m8iXxsQ42k7l/htZ7enlv2MJYOHmj6nYpolUnceTjrazi9hgNCA== X-Received: by 2002:a62:5a44:0:b029:19e:1324:c878 with SMTP id o65-20020a625a440000b029019e1324c878mr8929934pfb.65.1607644578659; Thu, 10 Dec 2020 15:56:18 -0800 (PST) Received: from mike-mac.lan (107-182-41-154.volcanocom.com. [107.182.41.154]) by smtp.gmail.com with ESMTPSA id nm6sm7806541pjb.25.2020.12.10.15.56.17 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 10 Dec 2020 15:56:17 -0800 (PST) To: Dave Crocker , "dmarc@ietf.org" References: <9d7e7d03-f8e9-7891-0d74-c50dfd2ac274@mtcc.com> <670e48f5-cb86-0a40-5c9a-712879323db8@mtcc.com> <1b4a2d04-affa-2162-7dbb-fde99d0e8288@gmail.com> From: Michael Thomas Message-ID: <8c677582-b5aa-4556-1b05-9fb5b430c9a2@mtcc.com> Date: Thu, 10 Dec 2020 15:56:16 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 MIME-Version: 1.0 In-Reply-To: <1b4a2d04-affa-2162-7dbb-fde99d0e8288@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] are mailing lists worth saving? X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 10 Dec 2020 23:56:21 -0000 On 12/10/20 3:45 PM, Dave Crocker wrote: > On 12/10/2020 3:34 PM, Michael Thomas wrote: >> I'm just making the observation > > > "Basically just declare" is not a linguistic form for 'just making an > observation'.  It's a proposal. > > A proposal that we face reality? I suppose in an odd sense of the word. Unless you have a different means of avoiding that fate after 16 years with a technical solution that has eluded everybody else, then nature will just take its course with more and more organizations setting up p=reject making it harder and harder to use mailing lists. As far as this working group goes, it seems the charter already takes this into account. ARC provides the fig leaf and DMARC is just getting cleaned up as the charter said to. Mike From nobody Thu Dec 10 16:23: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 6987E3A1371 for ; Thu, 10 Dec 2020 16:23:42 -0800 (PST) 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 HcZAYNixoV2I for ; Thu, 10 Dec 2020 16:23:41 -0800 (PST) Received: from mail-pl1-x631.google.com (mail-pl1-x631.google.com [IPv6:2607:f8b0:4864:20::631]) (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 71C293A1373 for ; Thu, 10 Dec 2020 16:23:41 -0800 (PST) Received: by mail-pl1-x631.google.com with SMTP id v3so3684795plz.13 for ; Thu, 10 Dec 2020 16:23:41 -0800 (PST) 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=GHCd5fTrF1Q9+6zrSo1C/iPsJJ53B2L+jGZnjlEh29w=; b=A3P9Yf/qc6afkonhPfyZuxZM5XfHOUUiG7nC6QKcR+a01DhFxojryQluk73uSv89Gg VCF16ekn0WUtpQgE0EcdsLMQVW3RYwxzu+5yM5Skpkx0oZ7z7b7f/Io5bTyKAFHrZ1DT UgB+fOr41INWRwKKU2FykTP9HbZTMFCVi+/dtXW/F60ALSGZdiIctrtJ05v06jl+3tzE REfZPJIvqJB7dkGAn+IaEaEEpKQec0M88FTne5BIOWjsSNKDwf5La500PGJHeK/JEROf 2UAx6KrP6RBIHOEBz7/a3KCovUr1Gtp82P9KTrQxCeBZmk74AE6FcnD8S+l4zTPyjglq G7Ug== 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=GHCd5fTrF1Q9+6zrSo1C/iPsJJ53B2L+jGZnjlEh29w=; b=lHnIDDkrAtE2JZuePibFfawqfdjbMvTNez/1RypxPXWltjcB0qsMtfh5yQ6N5AFPWA HhHu2908B4VOc9F4qGsEja+tidgsW8ucBc83IrDQNOedAt1/Obzoc76hvS/N7mehmawi I384iq2fvyKH1HQyxh9n4+Cx5eN4GaPOHWUfYEenGii3WFTUX2p1Kd81IjaqnuhSnKFv 9hR7a9VVKf2LztCpPtr9eHamZbphYri6NefR5AFHmYftyj9+EVmQgkNuVnUp/b0+f6aX zPWQliuUxoxq1uaO0KPvUnHSDnKprXFykCxk9+bffeEOT3ldBvCNcbx3Ae6Tt+sdlIJP tbVA== X-Gm-Message-State: AOAM5318EXbVfd48H9WQe5qpoLf2cTMbmA/kbGRwy95e0fJBDFUfAT+M 7GKIQZeWTouwEVWvzrhC037nikJiRHk= X-Google-Smtp-Source: ABdhPJxL1SZYjIRHv7seCAv8LE0gJFO9rXTESazorWF2XRd5zXH8vkctoX2+ZRLsndE4dwyvIp7lDg== X-Received: by 2002:a17:902:8c82:b029:da:c46c:aa44 with SMTP id t2-20020a1709028c82b02900dac46caa44mr8402288plo.26.1607646220664; Thu, 10 Dec 2020 16:23:40 -0800 (PST) Received: from [192.168.0.109] (c-24-130-62-181.hsd1.ca.comcast.net. [24.130.62.181]) by smtp.gmail.com with ESMTPSA id e8sm4562031pfn.176.2020.12.10.16.23.39 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 10 Dec 2020 16:23:40 -0800 (PST) To: Seth Blank Cc: Michael Thomas , "dmarc@ietf.org" References: <9d7e7d03-f8e9-7891-0d74-c50dfd2ac274@mtcc.com> <670e48f5-cb86-0a40-5c9a-712879323db8@mtcc.com> <1b4a2d04-affa-2162-7dbb-fde99d0e8288@gmail.com> From: Dave Crocker Message-ID: <35fb2f7f-c822-3905-f4b0-3cc11fdd3615@gmail.com> Date: Thu, 10 Dec 2020 16:23:39 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.5.1 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] are mailing lists worth saving? X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 11 Dec 2020 00:23:43 -0000 On 12/10/2020 3:52 PM, Seth Blank wrote: > Michael, Dave, this discussion is off topic. oops. ack. sorry. d/ -- Dave Crocker dcrocker@gmail.com 408.329.0791 Volunteer, Silicon Valley Chapter American Red Cross dave.crocker2@redcross.org From nobody Thu Dec 10 16:37: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 D14F43A137A for ; Thu, 10 Dec 2020 16:37:14 -0800 (PST) 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 ZnZILfEmeOfu for ; Thu, 10 Dec 2020 16:37:13 -0800 (PST) Received: from mail-io1-xd31.google.com (mail-io1-xd31.google.com [IPv6:2607:f8b0:4864:20::d31]) (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 4B5913A1377 for ; Thu, 10 Dec 2020 16:37:13 -0800 (PST) Received: by mail-io1-xd31.google.com with SMTP id r9so7718191ioo.7 for ; Thu, 10 Dec 2020 16:37:13 -0800 (PST) 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=7CuYRdSjxw8pZ3SZD8MfCCc2Ey967U8Q+z7qJGFlHB0=; b=J2LJa7ahq4WMhzEG6Wck0rW6s2+jstzNZvHI4WR+g/nWsEGKR9EF0zJc5YItbHeSiU j4dSdeZuu+d9OrRHizS0K9PmqC6rF2OjC5++Wq0Y2zdOBVKPq087a95bTIGn7uKqZ2MW Rkb1N+TQBdN++ByT13C4CBBgpxa2AKAlh1HzE= 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=7CuYRdSjxw8pZ3SZD8MfCCc2Ey967U8Q+z7qJGFlHB0=; b=IU/c3JWDz2aSZ/2NFv9pOlAHaqdawjuss4WlEupotf1OGZ8cOz5A89DaazzVUgj+eH BHvCg1vxrkuckJAy31gfo7rvfMkmVlflXLH165ev6ZQrdnQNNJinwM5UwRfQGN9OYDn9 Yg3yIiDO8/PqEy3PtNw2cSU2WOTjYY7qQ6ArEp8/PJlbSSy29x9p8j07X23o47uH6iUo 0E49dL5WEnPgJIjOiv8ollqsEnzpNtlVYBhfo4LaJ4ne1yn1BhWfhH5pdCTefu0Le/Ew Hjbk2qw6Jsj32GdonvMmczgcrp3K+vgNKsbOCDOSMbn0eq9G3Q8IsqPcJyafcOkkOPk2 e+hg== X-Gm-Message-State: AOAM531Nj0+QP0ZFuX9AAEW8YDr/VVnELm12pHaDu5vQdPrQEMKQxJ+U DDo3m5+4CYyotTW28Bsd4ZEKxKNJzQ6CrFrGjvtnsA== X-Google-Smtp-Source: ABdhPJxpbRdGhITUe4xFgdGdvIUHj1tbdypq7oIX9OIFxbhmJ6IXCGielHGbyHBCGDjPDTJTmT1eabS0+GT9QyyJB2g= X-Received: by 2002:a05:6602:8d:: with SMTP id h13mr11632744iob.163.1607647032595; Thu, 10 Dec 2020 16:37:12 -0800 (PST) MIME-Version: 1.0 References: <160745190172.15620.17081247178872475062@ietfa.amsl.com> In-Reply-To: <160745190172.15620.17081247178872475062@ietfa.amsl.com> From: "Kurt Andersen (b)" Date: Thu, 10 Dec 2020 16:37:01 -0800 Message-ID: To: Alexey Melnikov Cc: "dmarc@ietf.org" , "Murray S. Kucherawy" , dmarc-chairs@ietf.org Content-Type: multipart/alternative; boundary="0000000000004d64fd05b6257e3e" Archived-At: Subject: Re: [dmarc-ietf] dmarc - New Meeting Session Request for IETF 110 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 11 Dec 2020 00:37:15 -0000 --0000000000004d64fd05b6257e3e Content-Type: text/plain; charset="UTF-8" I'm wondering why we should wait for IETF110 rather than having an interim meeting sooner. Interim meetings are also likely to garner greater participation since they do not include participation fee. If there are topics worthy of F2F discussion, why wait? If there are not, then why charge people to join a pointless meeting? --Kurt On Tue, Dec 8, 2020 at 10:25 AM IETF Meeting Session Request Tool < session-request@ietf.org> wrote: > > > A new meeting session request has just been submitted by Alexey Melnikov, > a Chair of the dmarc working group. > > > --------------------------------------------------------- > Working Group Name: Domain-based Message Authentication, Reporting & > Conformance > Area Name: Applications and Real-Time Area > Session Requester: Alexey Melnikov > > > Number of Sessions: 1 > Length of Session(s): 1 Hour > Number of Attendees: 76 > Conflicts to Avoid: > Chair Conflict: dnsop dprive cfrg kitten emailcore > Technology Overlap: saag uta extra jmap cbor > > > > > > > People who must be present: > Alexey Melnikov > Murray Kucherawy > Tim Wicinski > Seth Blank > > Resources Requested: > > Special Requests: > > --------------------------------------------------------- > > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > --0000000000004d64fd05b6257e3e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I'm wondering why we should wait for IETF110 rather th= an having an interim meeting sooner. Interim meetings are also likely to ga= rner greater participation since they do not include participation fee. If = there are topics worthy of F2F discussion, why wait? If there are not, then= why charge people to join a pointless meeting?

--Kurt

On Tue, Dec 8, 2020 at 10:25 AM IETF Meeting Session Request Tool <<= a href=3D"mailto:session-request@ietf.org">session-request@ietf.org>= wrote:


A new meeting session request has just been submitted by Alexey Melnikov, a= Chair of the dmarc working group.


---------------------------------------------------------
Working Group Name: Domain-based Message Authentication, Reporting &amp= ; Conformance
Area Name: Applications and Real-Time Area
Session Requester: Alexey Melnikov


Number of Sessions: 1
Length of Session(s):=C2=A0 1 Hour
Number of Attendees: 76
Conflicts to Avoid:
=C2=A0Chair Conflict: dnsop dprive cfrg kitten emailcore
=C2=A0Technology Overlap: saag uta extra jmap cbor






People who must be present:
=C2=A0 Alexey Melnikov
=C2=A0 Murray Kucherawy
=C2=A0 Tim Wicinski
=C2=A0 Seth Blank

Resources Requested:

Special Requests:

---------------------------------------------------------


_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
--0000000000004d64fd05b6257e3e-- From nobody Thu Dec 10 16:46: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 B1A1B3A137A for ; Thu, 10 Dec 2020 16:46:21 -0800 (PST) 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 SD7BiBwRMNZd for ; Thu, 10 Dec 2020 16:46:20 -0800 (PST) Received: from mail-il1-x12e.google.com (mail-il1-x12e.google.com [IPv6:2607:f8b0:4864:20::12e]) (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 1BEE83A134E for ; Thu, 10 Dec 2020 16:46:20 -0800 (PST) Received: by mail-il1-x12e.google.com with SMTP id k8so7225918ilr.4 for ; Thu, 10 Dec 2020 16:46:20 -0800 (PST) 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=7m+hliiaswwk3fiYGySBdW32nXBvkSTh//yqdyPhHrI=; b=Y/3Bp6QuFxnrpUbyt5odtRWn34G/wkJPCJXcV2sbnVeWx0bD5ARrg98oZ/6ySOn5n1 wrUEB6RFBpDs8o8v/AOsTeOHcgBQ6rwmqXiETrSlyMSi7Fa3yKKzcncPm3ke9xXas/AC H7L2ZuvzUhjA61Hxv9tEg8NoUmWC+v6dpyhpc= 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=7m+hliiaswwk3fiYGySBdW32nXBvkSTh//yqdyPhHrI=; b=B//wHpSoIEoGlMTG2Dj6ZzyulcF8LL/eYW/l+KdfY4jzF1//3ez21kQRgCO14rRKPd snIjM1HYXwFOP/oekNZ1C9sxXfWpP3NqRZEEj+6YUTG7SRKOxqpjVfd9MzLVZopHZ5G8 9wtxiN/UqEPT/AyNyU/5dlMDp3SMHxmlHv4qwIjMAF10YaA7yjtXXW1PZoW1+J3KKNKZ S0tuk85T5oxfgP6gq/3X5jVS/yupGPEHVH7Gsme/SXGAw8ShaXlnuMM5thTLOpGmE4eZ MnLNJEZaHb2ipRS5eAhkSRYE+Nm0ZoI98eZnUnsSKSY/BTlanmHbsgmjLbNB24VUB9Mi CXhQ== X-Gm-Message-State: AOAM532VQdjGo5EkLDg+VDbX1CMrXbSO3BHRtClk0pZK8l2MUBYrBaMT ydVYgFZvq+vwX2ogVWyg/nMfLV2APB3XmvAFea6M4A== X-Google-Smtp-Source: ABdhPJxmIgs7FiQkIew4ThRRXtn6nN4nYVxMbhhKCvWDd9ekA+jX4YOx1BqAxmjYbT51s4e1Ij5V47qrKQXOcWNEZfQ= X-Received: by 2002:a05:6e02:12cc:: with SMTP id i12mr3644801ilm.23.1607647579436; Thu, 10 Dec 2020 16:46:19 -0800 (PST) MIME-Version: 1.0 References: <923de33f-3707-facf-389e-371f6ee64008@gmail.com> <16B0B820-7080-4937-8642-3A6B84B441AA@gmail.com> In-Reply-To: From: "Kurt Andersen (b)" Date: Thu, 10 Dec 2020 16:46:08 -0800 Message-ID: To: Dave Crocker Cc: IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000e5943b05b6259e59" Archived-At: Subject: Re: [dmarc-ietf] p=quarantine X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 11 Dec 2020 00:46:22 -0000 --000000000000e5943b05b6259e59 Content-Type: text/plain; charset="UTF-8" On Wed, Dec 9, 2020 at 10:09 AM Dave Crocker wrote: > It might be worth a bit of thinking about what, exactly, DMARC can > reasonably do and how it should be summarized, for popular consumption: > > *Alignment - *DMARC defines a basis for authenticating use of the domain > name in the rfc5322.From addr-spec. (But nothing else in that header field > or elsewhere in the message, neither header nor body. > > *Severity of unauthorized use - *DMARC provides a means of indicating to > receivers how serious the domain owner considers unauthorized use of that > domain name to be. > > *Reporting -* DMARC defines a mechanism for reporting DMARC-related > activity by a receiver > > I've tried to state each of these precisely and accurately, in terms of > real-world pragmatics. > These seem like a good starting point, but I'd have to quibble with the "*unauthorized use*" situation. This situation devolves into use-as-imagined vs. use-as-really-used when one considers various intermediary scenarios. Does a domain owner really have the prerogative to define recipient behaviour as "unauthorized"? --Kurt --000000000000e5943b05b6259e59 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Dec 9, 2020 at 10:09 AM Dave Croc= ker <dcrocker@gmail.com> wr= ote:
=20 =20 =20
It might be worth a bit of thinking about what, exactly, DMARC can reasonably do and how it should be summarized, for popular consumption:
Alignment - DMARC defines a basis for authenticating use of the domain name in the rfc5322.From addr-spec.=C2=A0 (But nothing else in that header field or elsewhere = in the message, neither header nor body.

Severity of unauthorized use - DMARC provides a means of indicating to receivers how serious the domain owner considers unauthorized use of that domain name to be.

Reporting - DMARC defines a mechanism for reporting DMARC-related activity by a receiver

I've tried to state each of these precisely and accurately, in terms of real-world pragmatics.

These seem= like a good starting point, but I'd have to quibble with the "= unauthorized use"=C2=A0 situation. This situation devolves into us= e-as-imagined vs. use-as-really-used when one considers various intermediar= y scenarios. Does a domain owner really have the prerogative to define reci= pient behaviour as "unauthorized"?

--Kur= t
--000000000000e5943b05b6259e59-- From nobody Thu Dec 10 17:00: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 E08563A1382 for ; Thu, 10 Dec 2020 17:00:16 -0800 (PST) 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 WIqxmDnCXQyB for ; Thu, 10 Dec 2020 17:00:15 -0800 (PST) Received: from mail-pl1-x632.google.com (mail-pl1-x632.google.com [IPv6:2607:f8b0:4864:20::632]) (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 B52D93A1380 for ; Thu, 10 Dec 2020 17:00:15 -0800 (PST) Received: by mail-pl1-x632.google.com with SMTP id p6so3735125plr.7 for ; Thu, 10 Dec 2020 17:00:15 -0800 (PST) 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=PUiRvJRZ5NMdpOfabXd4qD0KduOBF9DdmAT7Ht5MZeY=; b=ME2oz+m6oaMQz6E/Tcd89uSGkzP+RDnkgqBwWZk9vzXxCvlHEOAloqP4TcIMosKpWf xvCHtLMft148S2Gt1wEyFnvvk9dY2cjG/Iqn0R7F07iuLjoh+rddoAcsjbgnlbErNfCw x7sPr2japy9s5d1bDLojEBJd6Ndj7QXXTCEhpxZid6+i3hi/8cX3GGXcLADwv9hgVbEi Ls/z6R6GGaxp4njkspyEI4uELHwwrwPOfgeR+j2OuCZRSCvTgfdtNBcSKR3Vxz5zBlQL g+V36webPz3RdIYznyVUtnTIEet67A76BWcCZg8B+yLPCVDs4sNfv0yxh6QCYCS9Hoyl mVJg== 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=PUiRvJRZ5NMdpOfabXd4qD0KduOBF9DdmAT7Ht5MZeY=; b=ezKQ03pYhiVw0bSeoAfrRgD/IGI6nuznA1tq/M3ofXMmDx8UQDjFh0XSA88yiOTf44 B/cFRUnnGt0nFJ5B6pZiUfwjnhXN5El6lk2vn+3syQMOZS0+Kh1WK/WdnckpWmq2SecQ 54/if6azDdsgvnhx9PhM8rGPxY3WxLsnbZDEYEoypqzNBUMZxc107281r/famdRZxKLv Pe43EvBBCMRzxO4+zf+/Mnm/6aubEay6JmqBEyzxPIepO0QRXT9yVIED9oSk0p+YW7ZA 01yteap9HUSSJOk2eVGnVIu53ct2yhy2Qj5YsuFbMUaC9f7fed7KkoyGivtQt0FwknTr ER8w== X-Gm-Message-State: AOAM530UNmHPZ3QSmKdOrD+ayVDDYomfmQUZQhj9bsfvsxC/g2Swb2FK OIuTUsiskITFPr39buSfO6jQoNXqAQA= X-Google-Smtp-Source: ABdhPJxmkRLQPKiZRKOBjcJ7rZdgOEoFWSzNkbLwd40hEl5Ft7pYmbXLoAt+oUfqSaJzAaouUV5r+w== X-Received: by 2002:a17:902:76c8:b029:d9:d6c3:357d with SMTP id j8-20020a17090276c8b02900d9d6c3357dmr8587105plt.34.1607648414905; Thu, 10 Dec 2020 17:00:14 -0800 (PST) Received: from [192.168.0.109] (c-24-130-62-181.hsd1.ca.comcast.net. [24.130.62.181]) by smtp.gmail.com with ESMTPSA id js9sm9631288pjb.2.2020.12.10.17.00.13 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 10 Dec 2020 17:00:14 -0800 (PST) To: "Kurt Andersen (b)" Cc: IETF DMARC WG References: <923de33f-3707-facf-389e-371f6ee64008@gmail.com> <16B0B820-7080-4937-8642-3A6B84B441AA@gmail.com> From: Dave Crocker Message-ID: Date: Thu, 10 Dec 2020 17:00:13 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------9CA87D8515B00335A3CDC762" Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] p=quarantine X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 11 Dec 2020 01:00:17 -0000 This is a multi-part message in MIME format. --------------9CA87D8515B00335A3CDC762 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 12/10/2020 4:46 PM, Kurt Andersen (b) wrote: > but I'd have to quibble with the "*unauthorized use*"  situation. please do quibble. or more. I intended the text to prime the pump, and don't have any expectation is is already perfect. d/ -- Dave Crocker dcrocker@gmail.com 408.329.0791 Volunteer, Silicon Valley Chapter American Red Cross dave.crocker2@redcross.org --------------9CA87D8515B00335A3CDC762 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 12/10/2020 4:46 PM, Kurt Andersen (b) wrote:
but I'd have to quibble with the "unauthorized use"  situation.

please do quibble. or more.

I intended the text to prime the pump, and don't have any expectation is is already perfect.

d/

-- 
Dave Crocker
dcrocker@gmail.com
408.329.0791

Volunteer, Silicon Valley Chapter
American Red Cross
dave.crocker2@redcross.org
--------------9CA87D8515B00335A3CDC762-- From nobody Thu Dec 10 17:03: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 B69623A1382 for ; Thu, 10 Dec 2020 17:03:23 -0800 (PST) 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 mE7160sacs0A for ; Thu, 10 Dec 2020 17:03:22 -0800 (PST) Received: from mail-pg1-x52c.google.com (mail-pg1-x52c.google.com [IPv6:2607:f8b0:4864:20::52c]) (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 7BEBE3A1381 for ; Thu, 10 Dec 2020 17:03:22 -0800 (PST) Received: by mail-pg1-x52c.google.com with SMTP id f17so5984578pge.6 for ; Thu, 10 Dec 2020 17:03:22 -0800 (PST) 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=Ha07ytmYdiaLw3OP9YGz4JzkZ+CWkRQ/yIv/GETmbuA=; b=r1NV6gg0uUKVfbQvg28ax73tv437NRXsrf24eO1XrC2RFcs/PDP4yn453+GIfMfSZC 9Lp1ihV6qsltxa8YO9OsrqHJz1gF4eIifG3vFQGu6ztN6Yr7+WtNqNABMYrrLFHpdNs1 RNKySkZJF//sPK/Nh/c9HJ+EaR8RqohtXydgkC0UTcK+lD+IHez8wdWilB8GOZR3if/U qxAblkD0rLwahDpLJ8Kh/R3DiXxf9685mpT3TjDvY9inRsjdkF8clcB5zfK7LsqJE9n2 FeNpy8TOgY3bJR9T/vbKfEj18hs++sp6bcU0LQmzgN9Sir3r6Q8EZONOx4Wk8t3dOF9S TWhA== 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=Ha07ytmYdiaLw3OP9YGz4JzkZ+CWkRQ/yIv/GETmbuA=; b=hmic9mwnsJ7ejb36aZSvgOD1vEXomKuJsCBYOH98vxHfjp88evZEdYpkcbn4al+gyc R+KRq+2KqEs84EI5OWDD7SMtPBASD12LaqnjxxN3BLcvUCRgeBN06Qbz+2VgGpFKAyIW XdgIWwBFELsR0e5eYxWQjKIoAxjhrnkfIqgOFcAQPcXN6ycn5za1tbmRoVfqofD58ylo VgXcSAa9fnQhFl31sRE6KxjQFn2UJBE74KKCeB9haU9Ye1lNQpjVJX2a0LJ7jq3D9xkm re9h4EWHyaCicMr0r9J2yiAI8yEHSRGxD/CFLOANQS5tlZT7LnPe/mM3pK7rdd+CC4RQ k0NA== X-Gm-Message-State: AOAM531yD3/vREwezxF+0Az4r7biysLEFilq7VV7LrrntwQW6cL8xMz+ PFealzfIpqR/8tOTXSVJ6IF2m4RpWuE= X-Google-Smtp-Source: ABdhPJx2D9dxZzy7CkNhz2+wuHnOX1Y3e3TRxYq3me5QG2NAZ14fI5fU7qJ5Zr3b3UaADUQX6pBK1g== X-Received: by 2002:a17:90a:6a48:: with SMTP id d8mr10221001pjm.130.1607648601711; Thu, 10 Dec 2020 17:03:21 -0800 (PST) Received: from [192.168.0.109] (c-24-130-62-181.hsd1.ca.comcast.net. [24.130.62.181]) by smtp.gmail.com with ESMTPSA id x28sm7520764pff.182.2020.12.10.17.03.20 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 10 Dec 2020 17:03:20 -0800 (PST) To: "Kurt Andersen (b)" Cc: IETF DMARC WG References: <923de33f-3707-facf-389e-371f6ee64008@gmail.com> <16B0B820-7080-4937-8642-3A6B84B441AA@gmail.com> From: Dave Crocker Message-ID: <1f5b3e62-e6f4-0bc2-221e-362667536727@gmail.com> Date: Thu, 10 Dec 2020 17:03:20 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------A1BE13CB0C7E448C99A534AF" Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] p=quarantine X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 11 Dec 2020 01:03:24 -0000 This is a multi-part message in MIME format. --------------A1BE13CB0C7E448C99A534AF Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 12/10/2020 4:46 PM, Kurt Andersen (b) wrote: > to quibble with the "*unauthorized use*"  situation. This situation > devolves into use-as-imagined vs. use-as-really-used when one > considers various intermediary scenarios. (to respond to the content...) So, the driving issue is that it's characterizing problematic usage; use that did not achieve a DMARC pass. And, yeah, that doesn't mean the use was unauthorized, given the other possible explanations for failure. So, without suggesting a label, I'd describe this factor as "how serious is a failure to get a DMARC pass"?  If that's the right semantic, what's a reasonable label to use?  If it's not the right semantic, what is? d/ -- Dave Crocker dcrocker@gmail.com 408.329.0791 Volunteer, Silicon Valley Chapter American Red Cross dave.crocker2@redcross.org --------------A1BE13CB0C7E448C99A534AF Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 12/10/2020 4:46 PM, Kurt Andersen (b) wrote:
to quibble with the "unauthorized use"  situation. This situation devolves into use-as-imagined vs. use-as-really-used when one considers various intermediary scenarios.

(to respond to the content...)


So, the driving issue is that it's characterizing problematic usage; use that did not achieve a DMARC pass.

And, yeah, that doesn't mean the use was unauthorized, given the other possible explanations for failure.

So, without suggesting a label, I'd describe this factor as "how serious is a failure to get a DMARC pass"?  If that's the right semantic, what's a reasonable label to use?  If it's not the right semantic, what is?


d/

-- 
Dave Crocker
dcrocker@gmail.com
408.329.0791

Volunteer, Silicon Valley Chapter
American Red Cross
dave.crocker2@redcross.org
--------------A1BE13CB0C7E448C99A534AF-- From nobody Thu Dec 10 17:58: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 5977C3A13C4 for ; Thu, 10 Dec 2020 17:58:39 -0800 (PST) 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 HDkvK5nj6UKc for ; Thu, 10 Dec 2020 17:58:37 -0800 (PST) Received: from mail-ua1-x929.google.com (mail-ua1-x929.google.com [IPv6:2607:f8b0:4864:20::929]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 510CA3A0A2B for ; Thu, 10 Dec 2020 17:58:37 -0800 (PST) Received: by mail-ua1-x929.google.com with SMTP id p2so2381502uac.3 for ; Thu, 10 Dec 2020 17:58:37 -0800 (PST) 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=J1C8kn/onn/ZBwonuDGnSfDwOuVfeEIqj/HgcVqGcfo=; b=L3L+RVnuyFT2R6cJ2PQ5A6ix/By+61rqxouKxmnm/pm6kcC72fp7uwrRVPlvdCTk88 Hh/ze4Q7WErJzXZYoDbZ4cHjCuz7xY+COpudRJ1mc5CxfQb1chB9h84ovo52aI0vSNul lB2dOUw4GQM1xA2HufyR9jklhUvDYPBem7VYjIfiUILlYJuf1q4nlk/TOY1Zlk7ncXnU yQciWnTmMCDxWwDe/tUEvz/8dCfWbTJx0+SEyrQt+5QwTeOCBPRyh2aQh4c53flCgSek y7Dm5vnnEx/BsbNDOBmFTiQFTRk2akkCHxj1Hqs1BQa9tYiELtsduGX7Hd14LYsFCJS+ oQbg== 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=J1C8kn/onn/ZBwonuDGnSfDwOuVfeEIqj/HgcVqGcfo=; b=HiZk/21lN/37o7cWxG0diXXV9Woa+c3rxYrYbtGxvzHpCZyfdEjUlo2qVt9Dcl83sn rvzym5ZRwJRFMhvgAAqx+wBG/SXy0yp4m8kCOUq+PpVfoba7lnYVWGXLiBJpZ0qofjgn oM8ukLN311hnS7yZWfQtuS82qCKZI/CmCfBo9QDU12SX0/hNdAyQ6Q6vLCTmkEyZBg98 nw7/9ygepdmzGRmoBnLLcsEgj2e7+QRqb3Ph1Rltl+BXst0YcHT+qd+rjmGKoBly/bRH SVpEnpqWabYHamSDTPl+pXJaBIMT6ojD/Uz3OHm6omRyUH7v0VP+OTyYbFk9xs6DzLoJ l78Q== X-Gm-Message-State: AOAM5339ka6E495tI7Sjf2doG/doHh1YRfztIwtaqfiEWzZec58DtwbP D+QZGIv22xFY77eX/zUjAJTAAzR3DK85z/F8v0TQpTuIYKM= X-Google-Smtp-Source: ABdhPJzWqjtG143le7IvzyD4VE7g/OXGQvd0Sq5DZDHTlugTMlfY61UkOittMk+TiXRzc3A77GjOawAtaqADrdF76ZI= X-Received: by 2002:ab0:2a4a:: with SMTP id p10mr11479837uar.95.1607651916216; Thu, 10 Dec 2020 17:58:36 -0800 (PST) MIME-Version: 1.0 References: <9d7e7d03-f8e9-7891-0d74-c50dfd2ac274@mtcc.com> In-Reply-To: <9d7e7d03-f8e9-7891-0d74-c50dfd2ac274@mtcc.com> From: Douglas Foster Date: Thu, 10 Dec 2020 20:58:23 -0500 Message-ID: To: IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000637c2c05b626a127" Archived-At: Subject: Re: [dmarc-ietf] are mailing lists worth saving? X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 11 Dec 2020 01:58:39 -0000 --000000000000637c2c05b626a127 Content-Type: text/plain; charset="UTF-8" What you miss is that mailing lists are not the whole scope. All forwarding creates trust problems and all modifications by intermediaries will cause trust problems. Modification is done by many spam filters, and the prevalence of modification seems to be increasing. If any of that traffic is auto-forwarded, it also has the mailing list problem. Reverse transformation may help with the modification problem but it cannot help with the larger problems of forwarder trust. And there are many users of forwarding. A forwarder needs to do more than gain trust that it did nothing unacceptable, it also must help the recipient conclude that the originator did nothing unacceptable. We have lacked a strategy for doing this. Right now, forwarding under SPF and DMARC causes important information to be discarded. So they make the forwarding trust problem worse. Unverifiable Received entries make the problem even harder. ARC is a technology which should be able to address the forwarder trust problem, whether modification occurs or not. Whether it currently conveys all of the needed information to satisfy recipients must remain to be seen. I do not believe that it does at present, but I believe that it could and should. On Thu, Dec 10, 2020, 6:23 PM Michael Thomas wrote: > > On 12/10/20 2:58 PM, Dave Crocker wrote: > > On 12/9/2020 3:05 PM, Michael Thomas wrote: > > we know that amount of traffic going through mailing lists is tiny -- like > a couple percent. > > > Keeping in mind that mailing lists have been a legitimate Arpanet/Internet > email activity since the start of network email and that it is DMARC that > created operational problems, rather than mailing list activity creating > problems, the onus for declaring a nearly 50 year activity no longer > supported should be pretty compelling. It should not rely on anecdotes or > the views of an isolated few. And it certainly should not justify the > change with some broad, cavalier claims about security. > > For starters: > > - Please document attacks and other misbehaviors that have been > attributed to mailing list operation > - Please provide objective, validated documentation for you assertion > that the traffic through mailing lists is tiny. > - Please include similar substantiation for the percentage claim > - Please explain how this type of long-standing legitimate activity > can reasonably be otherwise conducted; a generic reference to the web is > not sufficient; what is needed is a point-for-point evaluation of mailing > list group and technical functionality and an comparison to replacement > choices. > > > This assumes that the IETF has any say whatsoever in this matter. It > doesn't. DMARC and ADSP before it gives the world the ability to say "i > don't care about mailing lists". Apparently Yahoo is one of them. That > horse has left the barn. Many domains would rather the security > improvements with p=reject. And it's not mailing lists that are the problem > per se, it is that the security posture that facilitating them leaves > organizations vulnerable to phishing attacks. Many organizations are giving > that a nope, and there is nothing we can do about that. > > There are many things that had their day and died because they couldn't > adapt, were redundant, or their time was just over. Usenet is a great > example. After 16 years of trying to deal with the mailing list problem, > we're right back where we started. Murray's hacks for recovering the > signature are not different in kind to my heuristics and hacks I did 15 > years ago. And ARC seems to boil down to requiring the previously unsolved > problem of "trusting" the mailing list. > > So no, I won't be doing any of those things because they are completely > beside the point. Feel free trying your hand solving it. > > Mike > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > --000000000000637c2c05b626a127 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
What you miss is that mailing lists are not the whole sco= pe.=C2=A0 All forwarding creates trust problems and all modifications by in= termediaries will cause trust problems.=C2=A0

=C2=A0=C2=A0Modification is done by many spam filters, and = the prevalence of modification seems to be increasing.=C2=A0 =C2=A0If any o= f that traffic is auto-forwarded, it also has the mailing list problem.

Reverse transfo= rmation may help with the modification problem but it cannot help with the = larger problems of forwarder trust.=C2=A0 And there are many users of forwa= rding.=C2=A0

A forwarder= needs to do more than gain trust that it did nothing unacceptable, it also= must help the recipient conclude that the originator did nothing unaccepta= ble.=C2=A0 =C2=A0We have lacked a strategy for doing this.

Right now, forwarding under SPF and DMAR= C causes important information to be discarded.=C2=A0 =C2=A0 So they make t= he forwarding trust problem worse.=C2=A0 Unverifiable Received entries make= the problem even harder.

ARC is a technology which should be able to address the forwarder trust p= roblem, whether modification occurs or not.=C2=A0 =C2=A0Whether it currentl= y conveys all of the needed information to satisfy recipients must remain t= o be seen.=C2=A0 I do not believe that it does at present, but I believe th= at it could and should.

=
On Thu= , Dec 10, 2020, 6:23 PM Michael Thomas <mike@mtcc.com> wrote:
=20 =20 =20


On 12/10/20 2:58 PM, Dave Crocker wrote:
=20
On 12/9/2020 3:05 PM, Michael Thomas wrote:
we know that amount of traffic going through mailing lists is tiny -- like a couple percent.


Keeping in mind that mailing lists have been a legitimate Arpanet/Internet email activity since the start of network email and that it is DMARC that created operational problems, rather than mailing list activity creating problems,=C2=A0 the onus for declaring a nearly 50 year activity no longer supported should be pretty compelling.=C2=A0 It should not rely on anecdotes or the views of an isolated few. And it certainly should not justify the change with some broad, cavalier claims about security.

For starters:=C2=A0

  • Please document attacks and other misbehaviors that have been attributed to mailing list operation
  • Please provide objective, validated documentation for you assertion that the traffic through mailing lists is tiny.
  • Please include similar substantiation for the percentage claim
  • Please explain how this type of long-standing legitimate activity can reasonably be otherwise conducted; a generic reference to the web is not sufficient; what is needed is a point-for-point evaluation of mailing list group and technical functionality and an comparison to replacement choices.

This assumes that the IETF has any say whatsoever in this matter. It doesn't. DMARC and ADSP before it gives the world the ability to say "i don't care about mailing lists". Apparently Y= ahoo is one of them. That horse has left the barn. Many domains would rather the security improvements with p=3Dreject. And it's not mailing lists that are the problem per se, it is that the security posture that facilitating them leaves organizations vulnerable to phishing attacks. Many organizations are giving that a nope, and there is nothing we can do about that.

There are many things that had their day and died because they couldn't adapt, were redundant, or their time was just over. Usenet is a great example. After 16 years of trying to deal with the mailing list problem, we're right back where we started. Murray's hacks for recovering the signature are not different in kind to my heuristics and hacks I did 15 years ago. And ARC seems to boil down to requiring the previously unsolved problem of "trusting" the mailing list.

So no, I won't be doing any of those things because they are completely beside the point. Feel free trying your hand solving it.

Mike

_______________________________________________
dmarc mailing list
dmar= c@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
--000000000000637c2c05b626a127-- From nobody Thu Dec 10 18:01: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 AB93D3A13F3 for ; Thu, 10 Dec 2020 18:01:24 -0800 (PST) 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 RNOFL968Jgy7 for ; Thu, 10 Dec 2020 18:01:22 -0800 (PST) Received: from mail-vs1-xe2a.google.com (mail-vs1-xe2a.google.com [IPv6:2607:f8b0:4864:20::e2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D25C3A1403 for ; Thu, 10 Dec 2020 18:01:17 -0800 (PST) Received: by mail-vs1-xe2a.google.com with SMTP id q10so3973529vsr.13 for ; Thu, 10 Dec 2020 18:01:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=U2RfZiyRmjDUeCv/pyFPyLvzpaIslpXjJqZDkZo6nFs=; b=Ojk2Xcl2uUPk75h7c8FEx+99JT7hBThieIH7+XAzqPk2QCTiWykV+eVp0TxWwLrPOt SItIjCNFG7CTqZBBuDZCk9Vyx/R3v+xHrXp11V0MUfet8i0qh9NO84L1IQ3AiD+uvY3y ieMkVxrgjnS/m83os1xuHzldcNuR/Zke4EbsNVymjDXULTi9u8KS19HzvCq51RIopfBl uo9uTj5JtHQjHD1/sCawRkne8ZFKVaV4iSOsR4N14zQBSK8/TGFBVUaIM5HP9mukWF7v 9SuIGD/gKA2zDxNtkuJ6btg+6v8L1O8Cyu8N5b5acYzDsNT6taIYVoZFMdwWfnRzaBOD r5Kw== 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=U2RfZiyRmjDUeCv/pyFPyLvzpaIslpXjJqZDkZo6nFs=; b=umOe5jCVT/H+9UVIJ0zsO4wqiZOOnuYTw8QXktEmQdWyM04Fuz5TX7fTvlf0CRYzn8 ZkvCgws560ZJ+GJUKmWoLY9u6yMQdJEPNjdykZMdPTRgXVyj5WcuCk41mFTxSqO8aTNe E2W/kk6xWYY5jREQ3ouB08P1/I6bbwbDVMilC6uwyQKBAAbCKGjX5r/tgttWo4E2kCAu zOFKrayf1ftxhBLidiVm6jhORNpZL91ALxYJTBY1y2AyWgomvjlVnFa1ZBcG6f6k7ndv LLI01QGnCBBoRENkEtzBslakLVXpGvQjoh1CrolSKkpNcX7lym7jFrEmqUbOBWuAECKc Vr5w== X-Gm-Message-State: AOAM532t+rDhu45B8tS1kDj79K/vHe6ehiMTgKIcu019LR74jZsRgpXx 7JeyYzrZzD/S4h/5ov34CSjVjrhHml17OrBI5stF2PIWRaA= X-Google-Smtp-Source: ABdhPJyDEcoSDLMJ8R+NfEv8HRJNnFs6zmyDO14mtYkUwE/vo4EsfgSmhmJwwTBgDaf/tcJhuNmTj4p7qKylK8gQPTg= X-Received: by 2002:a67:f454:: with SMTP id r20mr11887346vsn.35.1607652076474; Thu, 10 Dec 2020 18:01:16 -0800 (PST) MIME-Version: 1.0 References: <9d7e7d03-f8e9-7891-0d74-c50dfd2ac274@mtcc.com> In-Reply-To: From: Seth Blank Date: Thu, 10 Dec 2020 18:01:05 -0800 Message-ID: To: Douglas Foster , IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000f0f04a05b626aa75" Archived-At: Subject: Re: [dmarc-ietf] are mailing lists worth saving? X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 11 Dec 2020 02:01:32 -0000 --000000000000f0f04a05b626aa75 Content-Type: text/plain; charset="UTF-8" Doug, this thread is off topic. Please disengage. Seth, as Chair On Thu, Dec 10, 2020 at 17:58 Douglas Foster < dougfoster.emailstandards@gmail.com> wrote: > What you miss is that mailing lists are not the whole scope. All > forwarding creates trust problems and all modifications by intermediaries > will cause trust problems. > > Modification is done by many spam filters, and the prevalence of > modification seems to be increasing. If any of that traffic is > auto-forwarded, it also has the mailing list problem. > > Reverse transformation may help with the modification problem but it > cannot help with the larger problems of forwarder trust. And there are > many users of forwarding. > > A forwarder needs to do more than gain trust that it did nothing > unacceptable, it also must help the recipient conclude that the originator > did nothing unacceptable. We have lacked a strategy for doing this. > > Right now, forwarding under SPF and DMARC causes important information to > be discarded. So they make the forwarding trust problem worse. > Unverifiable Received entries make the problem even harder. > > ARC is a technology which should be able to address the forwarder trust > problem, whether modification occurs or not. Whether it currently conveys > all of the needed information to satisfy recipients must remain to be > seen. I do not believe that it does at present, but I believe that it > could and should. > > > On Thu, Dec 10, 2020, 6:23 PM Michael Thomas wrote: > >> >> On 12/10/20 2:58 PM, Dave Crocker wrote: >> >> On 12/9/2020 3:05 PM, Michael Thomas wrote: >> >> we know that amount of traffic going through mailing lists is tiny -- >> like a couple percent. >> >> >> Keeping in mind that mailing lists have been a legitimate >> Arpanet/Internet email activity since the start of network email and that >> it is DMARC that created operational problems, rather than mailing list >> activity creating problems, the onus for declaring a nearly 50 year >> activity no longer supported should be pretty compelling. It should not >> rely on anecdotes or the views of an isolated few. And it certainly should >> not justify the change with some broad, cavalier claims about security. >> >> For starters: >> >> - Please document attacks and other misbehaviors that have been >> attributed to mailing list operation >> - Please provide objective, validated documentation for you assertion >> that the traffic through mailing lists is tiny. >> - Please include similar substantiation for the percentage claim >> - Please explain how this type of long-standing legitimate activity >> can reasonably be otherwise conducted; a generic reference to the web is >> not sufficient; what is needed is a point-for-point evaluation of mailing >> list group and technical functionality and an comparison to replacement >> choices. >> >> >> This assumes that the IETF has any say whatsoever in this matter. It >> doesn't. DMARC and ADSP before it gives the world the ability to say "i >> don't care about mailing lists". Apparently Yahoo is one of them. That >> horse has left the barn. Many domains would rather the security >> improvements with p=reject. And it's not mailing lists that are the problem >> per se, it is that the security posture that facilitating them leaves >> organizations vulnerable to phishing attacks. Many organizations are giving >> that a nope, and there is nothing we can do about that. >> >> There are many things that had their day and died because they couldn't >> adapt, were redundant, or their time was just over. Usenet is a great >> example. After 16 years of trying to deal with the mailing list problem, >> we're right back where we started. Murray's hacks for recovering the >> signature are not different in kind to my heuristics and hacks I did 15 >> years ago. And ARC seems to boil down to requiring the previously unsolved >> problem of "trusting" the mailing list. >> >> So no, I won't be doing any of those things because they are completely >> beside the point. Feel free trying your hand solving it. >> >> Mike >> _______________________________________________ >> dmarc mailing list >> dmarc@ietf.org >> https://www.ietf.org/mailman/listinfo/dmarc >> > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > -- *Seth Blank* | VP, Standards and New Technologies *e:* seth@valimail.com *p:* 415.273.8818 This email and all data transmitted with it contains confidential and/or proprietary information intended solely for the use of individual(s) authorized to receive it. If you are not an intended and authorized recipient you are hereby notified of any use, disclosure, copying or distribution of the information included in this transmission is prohibited and may be unlawful. Please immediately notify the sender by replying to this email and then delete it from your system. --000000000000f0f04a05b626aa75 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Doug, this thread is off topic. Please disengage.


On Thu, Dec = 10, 2020 at 17:58 Douglas Foster <dougfoster.emailstandards@gmail.com> wrote:
What you miss is that mailing lists ar= e not the whole scope.=C2=A0 All forwarding creates trust problems and all = modifications by intermediaries will cause trust problems.=C2=A0

=C2=A0=C2=A0Modification is done by many= spam filters, and the prevalence of modification seems to be increasing.= =C2=A0 =C2=A0If any of that traffic is auto-forwarded, it also has the mail= ing list problem.

Reverse transformation may help with the modification problem but it = cannot help with the larger problems of forwarder trust.=C2=A0 And there ar= e many users of forwarding.=C2=A0

A forwarder needs to do more than gain trust that it did nothing = unacceptable, it also must help the recipient conclude that the originator = did nothing unacceptable.=C2=A0 =C2=A0We have lacked a strategy for doing t= his.

Right now, forwardi= ng under SPF and DMARC causes important information to be discarded.=C2=A0 = =C2=A0 So they make the forwarding trust problem worse.=C2=A0 Unverifiable = Received entries make the problem even harder.

<= /div>
ARC is a technology which should be able to address = the forwarder trust problem, whether modification occurs or not.=C2=A0 =C2= =A0Whether it currently conveys all of the needed information to satisfy re= cipients must remain to be seen.=C2=A0 I do not believe that it does at pre= sent, but I believe that it could and should.


On Thu, Dec 10, 2020, 6:23 PM Michael Thomas <mike@mtcc.com> wrote:
=20 =20 =20


On 12/10/20 2:58 PM, Dave Crocker wrote:
=20
On 12/9/2020 3:05 PM, Michael Thomas wrote:
we know that amount of traffic going through mailing lists is tiny -- like a couple percent.


Keeping in mind that mailing lists have been a legitimate Arpanet/Internet email activity since the start of network email and that it is DMARC that created operational problems, rather than mailing list activity creating problems,=C2=A0 the onus for declaring a nearly 50 year activity no longer supported should be pretty compelling.=C2=A0 It should not rely on anecdotes or the views of an isolated few. And it certainly should not justify the change with some broad, cavalier claims about security.

For starters:=C2=A0

  • Please document attacks and other misbehaviors that have been attributed to mailing list operation
  • Please provide objective, validated documentation for you assertion that the traffic through mailing lists is tiny.
  • Please include similar substantiation for the percentage claim
  • Please explain how this type of long-standing legitimate activity can reasonably be otherwise conducted; a generic reference to the web is not sufficient; what is needed is a point-for-point evaluation of mailing list group and technical functionality and an comparison to replacement choices.

This assumes that the IETF has any say whatsoever in this matter. It doesn't. DMARC and ADSP before it gives the world the ability to say "i don't care about mailing lists". Apparently Y= ahoo is one of them. That horse has left the barn. Many domains would rather the security improvements with p=3Dreject. And it's not mailing lists that are the problem per se, it is that the security posture that facilitating them leaves organizations vulnerable to phishing attacks. Many organizations are giving that a nope, and there is nothing we can do about that.

There are many things that had their day and died because they couldn't adapt, were redundant, or their time was just over. Usenet is a great example. After 16 years of trying to deal with the mailing list problem, we're right back where we started. Murray's hacks for recovering the signature are not different in kind to my heuristics and hacks I did 15 years ago. And ARC seems to boil down to requiring the previously unsolved problem of "trusting" the mailing list.

So no, I won't be doing any of those things because they are completely beside the point. Feel free trying your hand solving it.

Mike

_______________________________________________
dmarc mailing list
dmar= c@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
--

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


<= /p>

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

--000000000000f0f04a05b626aa75-- From nobody Thu Dec 10 18:01: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 C0ED13A13B2 for ; Thu, 10 Dec 2020 18:01:43 -0800 (PST) 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 0ZLBjT9ciS4w for ; Thu, 10 Dec 2020 18:01:41 -0800 (PST) Received: from mail-lf1-x12a.google.com (mail-lf1-x12a.google.com [IPv6:2a00:1450:4864:20::12a]) (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 DB62D3A13EF for ; Thu, 10 Dec 2020 18:01:35 -0800 (PST) Received: by mail-lf1-x12a.google.com with SMTP id o17so8261010lfg.4 for ; Thu, 10 Dec 2020 18:01:35 -0800 (PST) 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=KOxE/44ALdGznt/qR0KialiYzZ/LELa/mGYrEnR/ozQ=; b=OfRt/MbHrPt9eD22ofIhI8LhLdjwO+NG0MaYxwyY2WOnNrKpaLWJsPiSrLjx33EIaR 8PST2jXTMxxO4rlCaV0j7C6UtyMkbnuTAJy3APzF/u6vjqn87xKYBjkLsJOUiifoVIiB UcT+Oty3ftlGsVBHGkPwBBEDGRJZ9I01ajMVA= 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=KOxE/44ALdGznt/qR0KialiYzZ/LELa/mGYrEnR/ozQ=; b=HMHo7W5OmP2b1bwq3h0aQpOlms7fMyXiJzTYTsXQIeEIfm9tTlpFIpAXeMmgfnzguK NfAr7pL0XEgrmDFUzFO2904hWjkCahjQMZ0q5PeUn+xzAzS5JuNpJMDzILG2wHbcyXV+ /ElX26JXxuVb+NSNsU1L+sjaTE6PupKFiVeYFU1AD7xbSdg3nSIuQlnGa8jAssTmhkza gXB5pXohiAVS9cHiBa8I03mctMi/G9wK4OQccPV9NhFgFrZNm2UmjZS6+lI55ZLK+dWc 6ZgeILz4J+Ye35K+avyTRnwIeQO4EY8L/txuhShxecHmUWki0QoLPA3YLFnAo+IXE/cF QqQw== X-Gm-Message-State: AOAM530kvoJgJtvP+45vgVjvzn9BuNoeC/mjbcRdvMBrfms/uXjtlQkO LBfSC4S576W7wvh7nPXX1MlOihWmensfK5kb2wgU8g== X-Google-Smtp-Source: ABdhPJwBANwSmw98uo7Nc4wmwDc/3K0cmEBl4VfHUCHrTUKRBbe3lEekzb/iTDdStch07r2s9/MM8SfZHz6q4Mq6JFo= X-Received: by 2002:a19:5602:: with SMTP id k2mr3954209lfb.359.1607652094055; Thu, 10 Dec 2020 18:01:34 -0800 (PST) MIME-Version: 1.0 References: <923de33f-3707-facf-389e-371f6ee64008@gmail.com> <16B0B820-7080-4937-8642-3A6B84B441AA@gmail.com> <1f5b3e62-e6f4-0bc2-221e-362667536727@gmail.com> In-Reply-To: <1f5b3e62-e6f4-0bc2-221e-362667536727@gmail.com> From: "Kurt Andersen (b)" Date: Thu, 10 Dec 2020 18:01:21 -0800 Message-ID: To: Dave Crocker Cc: IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000fd391605b626ab18" Archived-At: Subject: Re: [dmarc-ietf] p=quarantine X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 11 Dec 2020 02:01:50 -0000 --000000000000fd391605b626ab18 Content-Type: text/plain; charset="UTF-8" On Thu, Dec 10, 2020 at 5:03 PM Dave Crocker wrote: > On 12/10/2020 4:46 PM, Kurt Andersen (b) wrote: > > to quibble with the "*unauthorized use*" situation. This situation > devolves into use-as-imagined vs. use-as-really-used when one considers > various intermediary scenarios. > > (to respond to the content...) > > So, the driving issue is that it's characterizing problematic usage; use > that did not achieve a DMARC pass. > > And, yeah, that doesn't mean the use was unauthorized, given the other > possible explanations for failure. > > So, without suggesting a label, I'd describe this factor as "how serious > is a failure to get a DMARC pass"? If that's the right semantic, what's a > reasonable label to use? If it's not the right semantic, what is? > I think that is much closer to the right semantic but highlights a problem that the mail coming from a particular domain probably doesn't rate a single broad-brush characterization of seriousness. --Kurt --000000000000fd391605b626ab18 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Dec 10, 2020 at 5:03 PM Dave Croc= ker <dcrocker@gmail.com> wr= ote:
=20 =20 =20
On 12/10/2020 4:46 PM, Kurt Andersen (b) wrote:
to quibble with the "unauthorized use"=C2=A0 situati= on. This situation devolves into use-as-imagined vs. use-as-really-used when one considers various intermediary scenarios.

(to respond to the content...)

So, the driving issue is that it's characterizing problematic usage; use that did not achieve a DMARC pass.

And, yeah, that doesn't mean the use was unauthorized, given the other possible explanations for failure.

So, without suggesting a label, I'd describe this factor as &quo= t;how serious is a failure to get a DMARC pass"?=C2=A0 If that's t= he right semantic, what's a reasonable label to use?=C2=A0 If it's not= the right semantic, what is?

I think that is much cl= oser to the right semantic but highlights a problem that the mail coming fr= om a particular domain probably doesn't rate a single broad-brush chara= cterization of seriousness.=C2=A0

--Kurt=C2=A0
--000000000000fd391605b626ab18-- From nobody Thu Dec 10 18:12: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 7080F3A13CC for ; Thu, 10 Dec 2020 18:12:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, 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=mtcc.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 EpX4wn7khnxQ for ; Thu, 10 Dec 2020 18:12:01 -0800 (PST) Received: from mail-pf1-x430.google.com (mail-pf1-x430.google.com [IPv6:2607:f8b0:4864:20::430]) (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 1228E3A13C8 for ; Thu, 10 Dec 2020 18:12:00 -0800 (PST) Received: by mail-pf1-x430.google.com with SMTP id t7so6020940pfh.7 for ; Thu, 10 Dec 2020 18:12:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mtcc.com; s=fluffulence; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=EEiqw7scfp0Ye1lLed/RGIKYFZptv8TQrZizHX8gmcY=; b=DK9tz0CYDmIBTPLb4BcZtLhGhKBHniLdJ4NyyMCIC2S9nvERcp1kjYzZ0YtJBI/9kK DRhjN5mQvXNtwywxGikGVcx8MyJv4TVd74Ft7QcgBSIymayZDmonsScGMlIaSrT96CmP cKUD9qosxhFgnXBbRtKjvW4SGzXnuUcrkKZdUFl+LQ66gHbehoBB6/THw4OfYnYD3fch z70EMc4Xr4AirZB2j6c04+UiXBjA4P7ThdDk51+u5P/ENCb1A84iSYh0wsbgFJDgOV64 RejLwgJENksodqTT70X1a9C6LmOxmIo4CWYGEL9hV4stXMH/iQBHs8jG+yeS41lZvO8p LdzQ== 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=EEiqw7scfp0Ye1lLed/RGIKYFZptv8TQrZizHX8gmcY=; b=P/gSxXbMXXQznSAnxB3T7LGE9NL9eN5Th14aIXLAbjPHf0AZGDJ72Gl6PnlZlU23f5 D0DgDqhP+9KavvdqvLYre/bhOT2P2dZT707Ranjh6E8RLpvpaqYPdZzWVSrwHwLE0m6+ K6WG6B7GtJIlsM3s2gnoDO0zVEbSVy356ixwzVzegNsbCvPe6rzH0sNlC8hEqQDP1kor 6RX3sNpMe/o5ihNyY+4XGT6vRIVIPf8kpw3uMSUVEBtakE/BcL+IaXbeuMPhQYfweo9t VJZ+NiNx6Awb+7xSv7NtIwB58gxEnxUZibMvSMkWvKwdZL3GUneFXPWNnCWK1nZJBfWm 4JoQ== X-Gm-Message-State: AOAM532NkrI36DKk2dXAO3PSMMQErk2B9AUBxJ6kqUdqTSnRbK6etiIP CiJJO4632pkQUP5ee3QCGy+hPagKQ4i3QA== X-Google-Smtp-Source: ABdhPJzjk81muzeSZeThHy980MUGYwXvAHgwnWPQlo4N5gTL2o1kID9qT2yK4zxbqKLoUFC4TTBVig== X-Received: by 2002:a65:5547:: with SMTP id t7mr9398493pgr.50.1607652719774; Thu, 10 Dec 2020 18:11:59 -0800 (PST) Received: from mike-mac.lan (107-182-41-154.volcanocom.com. [107.182.41.154]) by smtp.gmail.com with ESMTPSA id h7sm8824483pgi.90.2020.12.10.18.11.58 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 10 Dec 2020 18:11:59 -0800 (PST) To: Seth Blank , Dave Crocker Cc: "dmarc@ietf.org" References: <9d7e7d03-f8e9-7891-0d74-c50dfd2ac274@mtcc.com> <670e48f5-cb86-0a40-5c9a-712879323db8@mtcc.com> <1b4a2d04-affa-2162-7dbb-fde99d0e8288@gmail.com> From: Michael Thomas Message-ID: <2c63df68-a9bc-5d61-25c3-15c9223e0aa6@mtcc.com> Date: Thu, 10 Dec 2020 18:11:57 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------54F1CA47CB7BB0C0099800BA" Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] are mailing lists worth saving? X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 11 Dec 2020 02:12:03 -0000 This is a multi-part message in MIME format. --------------54F1CA47CB7BB0C0099800BA Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit So where is the proper place to discuss an ongoing IETF experiment? Seems sort of like catch-22. Mike On 12/10/20 3:52 PM, Seth Blank wrote: > Michael, Dave, this discussion is off topic. > > Please see the Chairs' note here: > https://mailarchive.ietf.org/arch/msg/dmarc/HhfoBzu_RlM4aiMbiLc4BaHjjmc/ > > > There will be a time to discuss indirect mail flow (and if we even > care about mailing lists) after the core bis tickets are addressed. > > Thank you. > > Seth, as Chair > > On Thu, Dec 10, 2020 at 3:45 PM Dave Crocker > wrote: > > On 12/10/2020 3:34 PM, Michael Thomas wrote: > > I'm just making the observation > > > "Basically just declare" is not a linguistic form for 'just making an > observation'.  It's a proposal. > > d/ > > -- > Dave Crocker > dcrocker@gmail.com > 408.329.0791 > > Volunteer, Silicon Valley Chapter > American Red Cross > dave.crocker2@redcross.org > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > > > > > -- > *Seth Blank*| VP, Standards and New Technologies > *e:*seth@valimail.com > *p:*415.273.8818 > > > This email and all data transmitted with it contains confidential > and/or proprietary information intended solely for the use of > individual(s) authorized to receive it. If you are not an intended and > authorized recipient you are hereby notified of any use, disclosure, > copying or distribution of the information included in this > transmission is prohibited and may be unlawful. Please immediately > notify the sender by replying to this email and then delete it from > your system. > --------------54F1CA47CB7BB0C0099800BA Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

So where is the proper place to discuss an ongoing IETF experiment? Seems sort of like catch-22.

Mike

On 12/10/20 3:52 PM, Seth Blank wrote:
Michael, Dave, this discussion is off topic.


There will be a time to discuss indirect mail flow (and if we even care about mailing lists) after the core bis tickets are addressed.

Thank you.

Seth, as Chair

On Thu, Dec 10, 2020 at 3:45 PM Dave Crocker <dcrocker@gmail.com> wrote:
On 12/10/2020 3:34 PM, Michael Thomas wrote:
> I'm just making the observation


"Basically just declare" is not a linguistic form for 'just making an
observation'.  It's a proposal.

d/

--
Dave Crocker
dcrocker@gmail.com
408.329.0791

Volunteer, Silicon Valley Chapter
American Red Cross
dave.crocker2@redcross.org

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


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


This 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.

--------------54F1CA47CB7BB0C0099800BA-- From nobody Thu Dec 10 18:21: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 BE1013A13D6 for ; Thu, 10 Dec 2020 18:21:23 -0800 (PST) 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 deyxlZnlaE57 for ; Thu, 10 Dec 2020 18:21:21 -0800 (PST) Received: from taos.firemountain.net (taos.firemountain.net [207.114.3.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8F063A1392 for ; Thu, 10 Dec 2020 18:21:21 -0800 (PST) Received: from gsp.org (localhost [127.0.0.1]) by taos.firemountain.net (8.15.1/8.14.9) with SMTP id 0BB2LKf1026182 for ; Thu, 10 Dec 2020 21:21:20 -0500 (EST) Date: Thu, 10 Dec 2020 21:21:20 -0500 From: Rich Kulawiec To: dmarc@ietf.org Message-ID: <20201211022120.GA32115@gsp.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [dmarc-ietf] are mailing lists worth saving? X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 11 Dec 2020 02:21:24 -0000 Yes, they are. I've been editing a document that lays out some of the strong arguments in their favor. It's still a draft (and may always be because I keep revising it), but here's a version of it: -------------- Mailing lists, which were sometimes called "reflectors" in their early days, are one of the older pieces of Internet technology. Despite that, they're still heavily used -- including by the very people who built and still run the Internet, people who could use anything they wanted. That's not an accident. It's because mailing lists have enormous technical advantages over the alternatives. Here are some of those: 1. Mailing lists require no special software: anyone with a sensible mail client can participate. Thus they allow you to use *your* software with the user interface of *your* choosing rather than being compelled to learn 687 different web forums with 687 different user interfaces, all of which range from "merely bad" to "hideously bad". 2. Mailing lists are simple: learn a few basic rules of netiquette and a couple of Internet-wide conventions, and one's good to go. Web forums are complicated because all of them are different. In other words, participating in 20 different mailing lists is just about as easy as participating in one; but participating in 20 different web forums is onerous. 3. They impose minimal security risk. 4. They impose minimal privacy risk. Points 3 and 4 stand in stark contrast to the security and privacy risks imposed on users of web forums and "social" media, especially the latter. 5. Mailing lists are bandwidth-friendly -- an increasing concern for people on mobile devices and thus on expensive data plans. Web forums are bandwidth-hungry. 6. Mailing lists interoperate. I can easily forward a message from one list to another one. Or to a person. I can send a message to multiple lists. I can forward a message from a person to a list. And so on. Try doing this with web forum software A on host B with destinations web forum software X and Y on hosts X1 and Y1. Good luck with that. 7. They're asynchronous: you don't have to interact in real time. You can download messages when connected to the Internet, then read them and compose responses when offline. 8. As a result of 7, They work reasonably well even in the presence of multiple outages and severe congestion. Messages may be delayed, but once everything's up again, they'll go through. Web-based forums simply don't work. 9. They're push, not pull, so new content just shows up. Web forums require that you go fishing for it. 10. They scale beautifully. 11. (When properly run) they're relatively free of abuse vectors. Mailing lists are highly resistant to abuse. Web forums, because of their complexity, are highly vulnerable to software security issues as well as spam/phishing and other attacks. 12. They handle threading well. And provided users take a few seconds to edit properly, they handle quoting well. 13. They're portable: lists can be rehosted (different domain, different host) rather easily. 14. They can be freely interconverted -- that is, you can move a list hosted by A using software B on operating system C to host X using software Y on operating system Z. 15. They can be written to media and read from it. This is a very non-trivial task with web forums. 16. The computing resources require to support them are minimal -- CPU, memory, disk, bandwidth, etc. 17. Mailing lists can be uni- or bidirectionally gatewayed to Usenet. (The main Python language mailing list is an example of this.) This can be highly useful. 18. They're easily archivable in a format that is simple and likely to be readable long into the future. Mail archives from 10, 20, even 30 or more years ago are still completely usable. And they take up very little space. [ Numerous tools exist for handling Unix "mbox" format: for example, "grepmail" is a highly useful basic search tool. Most search engines include parsers for email, and the task of ingesting mail archives into search engines is very well understood. ] 19. You can archive them locally... 20. ...which means you can search them locally with the software of *your* choice. Including when you're offline. And provided you make backups, you'll always have an archive -- even if the original goes away. Web forums don't facilitate this. [ Those of us who've been around for a while have seen a lot of web-based discussions vanish forever because a host crashed or a domain expired or a company went under or a company was acquired or someone made a mistake or there was a security breach or a government confiscated it. ] There's more, but I think this easily suffices to make a slamdunk case. Frank Zappa once said that you can't be a real country unless you have a beer and an airline. I don't think you can take an organization or a project seriously unless it has a mailing list and/or a newsgroup. Of course there's always a temptation to rush to the latest greatest shiny thing because it's new and shiny, but those come and go, and they depend on the vagaries of the companies behind them. Many painful object lessons in the impermanence of such things may be found at http://archiveteam.org -- whose contributors have invested heavily in attempts to mitigate the consequences of ill-advised decision-making by others. [ One metric -- of many -- for assessing such operations is to ask this question: can you export ALL of your data and ALL of your metadata from them, at will, and in a portable, open, usable format? The answer is almost always no. Even allegedly open operations like Google Groups fail this test. And if you can't do that, then you should immediately rule out using it. ] Not to mention that many of those latest greatest shiny new things come equipped with hideous privacy and security issues that can't be fixed because they're fundamental parts of the design. Not that mailing lists are immune to these -- they're not -- but the privacy and security exposure is far less. -------------- Mailing lists may not be a significant percentage of overall email traffic, but they're a valuable resource and it would be extraordinarily foolish to even consider getting rid of them. ---rsk From nobody Thu Dec 10 18:25: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 1CC033A13E0 for ; Thu, 10 Dec 2020 18:25:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, 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=mtcc.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 XXQMHdwfpwtp for ; Thu, 10 Dec 2020 18:25:14 -0800 (PST) Received: from mail-pj1-x102c.google.com (mail-pj1-x102c.google.com [IPv6:2607:f8b0:4864:20::102c]) (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 2D4413A13D6 for ; Thu, 10 Dec 2020 18:25:14 -0800 (PST) Received: by mail-pj1-x102c.google.com with SMTP id iq13so1435970pjb.3 for ; Thu, 10 Dec 2020 18:25:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mtcc.com; s=fluffulence; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=CSvUvi+1B/FlLn1tuHk0hj/WI4PuGyde5qrpb48HAUY=; b=Seaqvg27YQxR2KIXLKFjLPC3gqISwzGfa6Jx7Y8+bYXSJeGdS+Nw3ZQu7ZtmcAYOeV YmimFjH+EKdZWNKBY23PFEbKkZlJ0s2klDJZ9RSuf6UIX4cL/XXGl+3Y+1ol6jpkQT/x fEJI+9d/vrJTChom1C9tS/jVPH6rxhl56huPBJLk1Uk+iV91Kh4Z7phAaaLFrtq46FGh 7kW/9vqkHLdGKE+X9Pu++IK6a/0T89GuDX6Gy9yxblBC+Xr0DcMgg7Z0Yz/q6DXbBcxu J8w5Z1D6J58ZMYjDKTjHglD51SeioOjOXSy007ugpBxCbqDJ5gAkD2mKACrlTYRa24kR T8KQ== 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=CSvUvi+1B/FlLn1tuHk0hj/WI4PuGyde5qrpb48HAUY=; b=JdF3yIPrcTnQ5ocSai119yFXEV8pEcAR88og6tO6SNh2sRv9v03gxoI9h4ZaWD3sR6 m5eKSU14cINxYrWtU41GBtSu3rlUCRODGq8piKm7hkTMDRiwPsCpmD09X02bhr5s2ZZv Vz1KulWltAHnAHChuM/+NXpsq5AG5gI08yxoU1s63Jz9aob2ER+hL1VUc3Kq3pTa/DtO QPyneS9MbMTPJPQPThXk2N9qaBPHUZFuIquJE6ZXH7jS23qI27vo0h2Og3DyxhtxsW+Y 6132XRprFlNUr3+Y6QRFsWZME+giopZdZsNHdU8lNE5tm/IRExZl36PVISMErH0qQl5a ZKjw== X-Gm-Message-State: AOAM531HTbdnUSQWU9ysCQng5Wfefq6zkraQueE1YiSwsyDb+sGtVb9V NoL+JPc3YG82Owgjwkn8f5Zrv+i9gUUZrA== X-Google-Smtp-Source: ABdhPJyirlLHzduTLXOg2QAuKMSVxTEv74prq9o5XYNrTFvTOadmfPX6/PRku5DYqgfmqVZhDPBgzQ== X-Received: by 2002:a17:902:6803:b029:da:1469:8945 with SMTP id h3-20020a1709026803b02900da14698945mr8860222plk.15.1607653513165; Thu, 10 Dec 2020 18:25:13 -0800 (PST) Received: from mike-mac.lan (107-182-41-154.volcanocom.com. [107.182.41.154]) by smtp.gmail.com with ESMTPSA id h31sm7840139pgh.42.2020.12.10.18.25.12 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 10 Dec 2020 18:25:12 -0800 (PST) To: dmarc@ietf.org References: <923de33f-3707-facf-389e-371f6ee64008@gmail.com> <16B0B820-7080-4937-8642-3A6B84B441AA@gmail.com> <1f5b3e62-e6f4-0bc2-221e-362667536727@gmail.com> From: Michael Thomas Message-ID: Date: Thu, 10 Dec 2020 18:25:11 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------366032D6C50EF0D00FB9F150" Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] p=quarantine X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 11 Dec 2020 02:25:16 -0000 This is a multi-part message in MIME format. --------------366032D6C50EF0D00FB9F150 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 12/10/20 6:01 PM, Kurt Andersen (b) wrote: > On Thu, Dec 10, 2020 at 5:03 PM Dave Crocker > wrote: > > On 12/10/2020 4:46 PM, Kurt Andersen (b) wrote: >> to quibble with the "*unauthorized use*"  situation. This >> situation devolves into use-as-imagined vs. use-as-really-used >> when one considers various intermediary scenarios. > > (to respond to the content...) > > So, the driving issue is that it's characterizing problematic > usage; use that did not achieve a DMARC pass. > > And, yeah, that doesn't mean the use was unauthorized, given the > other possible explanations for failure. > > So, without suggesting a label, I'd describe this factor as "how > serious is a failure to get a DMARC pass"?  If that's the right > semantic, what's a reasonable label to use?  If it's not the right > semantic, what is? > > I think that is much closer to the right semantic but highlights a > problem that the mail coming from a particular domain probably doesn't > rate a single broad-brush characterization of seriousness. > I think this all should be driven by "what are you asking me to do?". p=quarantine is asking for a specific thing, but it doesn't seem to mean literally what it's asking for. it seems to mean "i'm not comfortable with this except in certain situations that i can't enumerate with any accuracy". maybe p=quarantine is my "only if you trust the intermediary" state I was talking about the other day. Mike --------------366032D6C50EF0D00FB9F150 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit


On 12/10/20 6:01 PM, Kurt Andersen (b) wrote:
On Thu, Dec 10, 2020 at 5:03 PM Dave Crocker <dcrocker@gmail.com> wrote:
On 12/10/2020 4:46 PM, Kurt Andersen (b) wrote:
to quibble with the "unauthorized use"  situation. This situation devolves into use-as-imagined vs. use-as-really-used when one considers various intermediary scenarios.

(to respond to the content...)

So, the driving issue is that it's characterizing problematic usage; use that did not achieve a DMARC pass.

And, yeah, that doesn't mean the use was unauthorized, given the other possible explanations for failure.

So, without suggesting a label, I'd describe this factor as "how serious is a failure to get a DMARC pass"?  If that's the right semantic, what's a reasonable label to use?  If it's not the right semantic, what is?

I think that is much closer to the right semantic but highlights a problem that the mail coming from a particular domain probably doesn't rate a single broad-brush characterization of seriousness. 

I think this all should be driven by "what are you asking me to do?". p=quarantine is asking for a specific thing, but it doesn't seem to mean literally what it's asking for. it seems to mean "i'm not comfortable with this except in certain situations that i can't enumerate with any accuracy". maybe p=quarantine is my "only if you trust the intermediary" state I was talking about the other day.

Mike

--------------366032D6C50EF0D00FB9F150-- From nobody Thu Dec 10 18:26: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 69F593A13E0 for ; Thu, 10 Dec 2020 18:26:03 -0800 (PST) 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, 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 dXeQXZdAHbJa for ; Thu, 10 Dec 2020 18:26:02 -0800 (PST) Received: from mail-pl1-x633.google.com (mail-pl1-x633.google.com [IPv6:2607:f8b0:4864:20::633]) (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 4A0FD3A13D6 for ; Thu, 10 Dec 2020 18:26:02 -0800 (PST) Received: by mail-pl1-x633.google.com with SMTP id r4so3829825pls.11 for ; Thu, 10 Dec 2020 18:26:02 -0800 (PST) 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=qalFmSfRkXUfmQqYWF9pTPVR/IYwTxWXLoyFAb3+Izg=; b=SWnRTUuxwKsSsdj0fOwc7ZxjNjc4XYZQryKW2AE6zLdqt5v+08ZbChEEcpqBAxusjL N/aFILJQXURQ6QwniLnwMazDTC0TBmX3FEjRFmctvOoCapg5m9qk0fTgoTsV6PX4zdRS x2tkPNF48WRX5LRzE0MshfCN8ofZTRb64aZyNa0drbM6ceoJ+0OwvEQMTKSeIPt4J0mw TxhF63P4sMt48ZhDd7E4nRkKyXyqtKDxjDKjUoqfyfmHiVkonWHCcqiXzutIUkKGpLcC jV84SsUotRDDOZaI5L+kFDqB1j1XUWx6LEDDUvk9miF6R0cDDA8j4sl0gwntxKbnV13I Zg2A== 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=qalFmSfRkXUfmQqYWF9pTPVR/IYwTxWXLoyFAb3+Izg=; b=bplQamT07Xf5gJOgAmxpVIEvAp+mPpEWtWda92ti9Ng4//0eFaskCyuLQU+VN2wx8D ORKBqeIB3YLzkqJjW9/RCfwq8HBuk6vMSKSXqehGUwP6GKv0UrB90M2N9yVBNMJvG7VC YJUKZ9lW7jaUprqlsTd563zCm3jvK3tOC0mIGJoA1TwoZOLfQEHdblDpYGVXg6ISZKqw +n2/ZigAHSEDlOiEwCd200K4yEH8INowFrmLkmEsT7aeB7k29LesW6IMFHlg5x4t8CJX qXkgoYXUvERmDn39nxHEfVjGaslZCbQGQaUgY3C89iTNooWb+VnOAIO0G5/dFO/6dkPA 6wPw== X-Gm-Message-State: AOAM532n4F2O6Gp4WOP7xU0yzg9jOpziQdZJ8RQSPFjYlEELVad5Dq8E k9fqCy+vWF2tuRqqUSX1I3JOg6b4HY4= X-Google-Smtp-Source: ABdhPJyjCwsPOeNwY/JXKMDCg82EHsV0jZk44eA4HmxYYhz7MxYF+k9IqkDICom0JrX8HS/l6QSkAg== X-Received: by 2002:a17:90a:1782:: with SMTP id q2mr10799979pja.189.1607653561535; Thu, 10 Dec 2020 18:26:01 -0800 (PST) Received: from [192.168.0.109] (c-24-130-62-181.hsd1.ca.comcast.net. [24.130.62.181]) by smtp.gmail.com with ESMTPSA id x5sm5368576pgj.68.2020.12.10.18.26.00 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 10 Dec 2020 18:26:01 -0800 (PST) To: "Kurt Andersen (b)" Cc: IETF DMARC WG References: <923de33f-3707-facf-389e-371f6ee64008@gmail.com> <16B0B820-7080-4937-8642-3A6B84B441AA@gmail.com> <1f5b3e62-e6f4-0bc2-221e-362667536727@gmail.com> From: Dave Crocker Message-ID: <8e0ff141-2842-606c-91e9-e588edab7ef1@gmail.com> Date: Thu, 10 Dec 2020 18:26:00 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] p=quarantine X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 11 Dec 2020 02:26:04 -0000 On 12/10/2020 6:01 PM, Kurt Andersen (b) wrote: > I think that is much closer to the right semantic but highlights a > problem that the mail coming from a particular domain probably doesn't > rate a single broad-brush characterization of seriousness. I've assumed the none, quarantine, reject choices are meant to indicate just how certain the domain owner is that the mail is problematic. Perhaps:     none: not certain at all     quarantine: I believe I've got control of all my sending, but am not 100% positive     reject: I have control of all my sending; if it doesn't pass DMARC, it's use of the domain is bogus. d/ -- Dave Crocker dcrocker@gmail.com 408.329.0791 Volunteer, Silicon Valley Chapter American Red Cross dave.crocker2@redcross.org From nobody Thu Dec 10 18:28: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 ACDEC3A13E4 for ; Thu, 10 Dec 2020 18:28:30 -0800 (PST) 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 LEiFlxUL0K0n for ; Thu, 10 Dec 2020 18:28:29 -0800 (PST) Received: from mail-pl1-x62a.google.com (mail-pl1-x62a.google.com [IPv6:2607:f8b0:4864:20::62a]) (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 9F3243A13E2 for ; Thu, 10 Dec 2020 18:28:29 -0800 (PST) Received: by mail-pl1-x62a.google.com with SMTP id r4so3832400pls.11 for ; Thu, 10 Dec 2020 18:28:29 -0800 (PST) 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=4XtgGo6AhCdOKrxouANIt/sjO9ieybZ1Pp5hQfcd1N0=; b=ldhys8QWNNbz9uIrxTKGvReaqUceNClkwYJpxlt3ZC5R9ZiNjTd/bJExXnr+h579/Y wdRVgJPRk662VhOr083vebgz8oSu27FDFp51HqHwSH8p/nz/ctiIm5JA1SOX4nuLWgxu 2iz+M72KH+1XyPePjgvt8JDnkXP1A7XDOmujQDJDLSiefH7QBjX6607mynpxydzAiBFM 0sFbS2B402bu91/xeGyx0G+G57Kci5CSghsDo0ENM2vW9uhxaneAyk0Zy7RekYh2//tB LJePqkc6HW5hX7/PfehoAtC7KAa3en7DcCjn1JkIo8YazRlx5i2dyBuZ8e1/p8t/1Y/n JaSA== 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=4XtgGo6AhCdOKrxouANIt/sjO9ieybZ1Pp5hQfcd1N0=; b=CsdOMz4faVxEThULzIocuTieZRZVLHzLrInfwmsRgTMflaGQTxJxnYlxCwN+ElIqxW 2QIAsPXbKogFhbW9dFD+ieRuM44Rvz3OmSFGTP/1ViEo0K/nsXRMWawoePrOi4QO8mo5 I7ICLz38FSmxHt8C/pZDYbQEly1XE2jhO3bYvfPGehJwRtKfwknqAI1eIP7cTGvQVCM4 4NRgB3Hia9NvdT7wRnzwfiuaqHE2KA1pKktLyGX7BeKegjDRyRWgVb4mD3b0E5Sw4MbG dfbHSG8PkIlZDIuwOtZIQWVzjNAodh8fvLUebq3KLgqP5eB2jf13PTfy8leJtO1zYbCa YEtA== X-Gm-Message-State: AOAM531KonOKFN7BhF3RdVBcSG8i+TBoGT1OQW0EtH+x474f2jG+qxUu wXZl3pOiX2FCTPQ+koyWiMy3sNtFxUI= X-Google-Smtp-Source: ABdhPJxLHQeJL/KkjT2JymI3oxanl7a+8JHTmkh2kKopJEFP/1XeVj8p4+QqHk1liTWKuyCwpp2EHg== X-Received: by 2002:a17:902:bd84:b029:da:17d0:e754 with SMTP id q4-20020a170902bd84b02900da17d0e754mr8813538pls.68.1607653708949; Thu, 10 Dec 2020 18:28:28 -0800 (PST) Received: from [192.168.0.109] (c-24-130-62-181.hsd1.ca.comcast.net. [24.130.62.181]) by smtp.gmail.com with ESMTPSA id b19sm7721103pfo.24.2020.12.10.18.28.28 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 10 Dec 2020 18:28:28 -0800 (PST) To: Michael Thomas , dmarc@ietf.org References: <923de33f-3707-facf-389e-371f6ee64008@gmail.com> <16B0B820-7080-4937-8642-3A6B84B441AA@gmail.com> <1f5b3e62-e6f4-0bc2-221e-362667536727@gmail.com> From: Dave Crocker Message-ID: <07bdeba8-639e-f05f-6981-d4f59040612f@gmail.com> Date: Thu, 10 Dec 2020 18:28:27 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] p=quarantine X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 11 Dec 2020 02:28:31 -0000 On 12/10/2020 6:25 PM, Michael Thomas wrote: > I think this all should be driven by "what are you asking me to do?" The domain owner has no business asking the receiver to do anything.  The receiver has no relationship with the domain owner. However, the receiver might like to hear the domain owner's opinion about usage of the domain when DMARC fails.  But that's different from attempting to give direction to the receiver (who demonstrably will ignore that direction and make their own decision.) d/ -- Dave Crocker dcrocker@gmail.com 408.329.0791 Volunteer, Silicon Valley Chapter American Red Cross dave.crocker2@redcross.org From nobody Thu Dec 10 18:29: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 539A03A13E1 for ; Thu, 10 Dec 2020 18:29:54 -0800 (PST) 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 e2qTdelDUvGs for ; Thu, 10 Dec 2020 18:29:53 -0800 (PST) Received: from mail-pg1-x532.google.com (mail-pg1-x532.google.com [IPv6:2607:f8b0:4864:20::532]) (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 22D373A13E0 for ; Thu, 10 Dec 2020 18:29:52 -0800 (PST) Received: by mail-pg1-x532.google.com with SMTP id t37so6134811pga.7 for ; Thu, 10 Dec 2020 18:29:52 -0800 (PST) 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=DC4v/PUXywR4fTosRr/SuYUBs1daCwXCA0LYNOtioZs=; b=ogIX5qG7z+L0+KXLMHBUd7F2AaklLMxymXIh/Uo1+9BEI4+fUntV3iaIVoZZshw3BK o5c8pSUYpTwd459tkAj1ulRX9OB9fMRkrcqpK2MrFTOK5gKwc8K6roxkaTFAQHLATA1B 1rCA1n/WZlHmlYFkzBFEPo0knlq8UcZuGFlz8yJCSPjbe9H5t0NAFkwPdMGN+8EJBOb1 VkXIi4Oq+pCWPH6laeUGTKibj5C1HIl94z1gu/+rLn/O9oc85kBSll2VyW4mAPzKpTmw kun6fv8cMTARWar9lfNT1CDNH1T8Zs81d1JOQZqSLz8NVy0H0Se75Ujdfhr0POWjCHZE V0tQ== 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=DC4v/PUXywR4fTosRr/SuYUBs1daCwXCA0LYNOtioZs=; b=Rd3fDS+XbdIGGHvsa6Q1rAUxfdFX8p83FqS5g33h+XboGw1sdPC3e536lGEjfoeon0 DG0af8qWEawMh5xXmk5wcuf70UjmkBv/wWlu4KxOkr8Q5Qh3tbnHEjO+GfRP6iSlasyp IZCASEUTA3Kw0KXiz+ztNm5ht0x3+o4FEKQEMhKyU+z9tDL9M9lij+aL5+1NbEb+fb84 vLAgZBRyJ+6piPGRxLXxjryfdTMqmden1X1j5IaySjz415jKsIhedYHstcZy8feN6rE2 R1YjScKUmEuKmQ3Zx5qWz7nC76Pc6y3SHGTVqMgQVfD42zpKlObzpwTtBlv3mfdkSd5S /oqQ== X-Gm-Message-State: AOAM532KZKkjamaksVdYxD4AN/NQT7i/jdzhVeHnmQ5vM3H9pF1xZCpQ yyvnug6+SS+LTFK9Sq0UUfTJ0lqcpgU= X-Google-Smtp-Source: ABdhPJytmycvkf5tvvJoHO72Nr1CvyCu4TCiwscUXKZtvsKi6S2h+tUeCqneovU2UkbcP1KLWq6G8Q== X-Received: by 2002:a63:1d60:: with SMTP id d32mr9376750pgm.343.1607653792357; Thu, 10 Dec 2020 18:29:52 -0800 (PST) Received: from [192.168.0.109] (c-24-130-62-181.hsd1.ca.comcast.net. [24.130.62.181]) by smtp.gmail.com with ESMTPSA id y6sm8161232pjl.0.2020.12.10.18.29.51 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 10 Dec 2020 18:29:51 -0800 (PST) To: Rich Kulawiec , dmarc@ietf.org References: <20201211022120.GA32115@gsp.org> From: Dave Crocker Message-ID: Date: Thu, 10 Dec 2020 18:29:51 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.5.1 MIME-Version: 1.0 In-Reply-To: <20201211022120.GA32115@gsp.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] are mailing lists worth saving? X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 11 Dec 2020 02:29:54 -0000 On 12/10/2020 6:21 PM, Rich Kulawiec wrote: > but here's a version of it: Just a thought, but the topic of mailing lists is both on-topic and currently being discussed, in the emailcore working group. d/ -- Dave Crocker dcrocker@gmail.com 408.329.0791 Volunteer, Silicon Valley Chapter American Red Cross dave.crocker2@redcross.org From nobody Thu Dec 10 18:32: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 956BA3A13E0 for ; Thu, 10 Dec 2020 18:32:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.751 X-Spam-Level: X-Spam-Status: No, score=-1.751 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, 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=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mtcc.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 tqpcwZraAWSZ for ; Thu, 10 Dec 2020 18:32:52 -0800 (PST) Received: from mail-pl1-x630.google.com (mail-pl1-x630.google.com [IPv6:2607:f8b0:4864:20::630]) (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 7B85E3A13E4 for ; Thu, 10 Dec 2020 18:32:52 -0800 (PST) Received: by mail-pl1-x630.google.com with SMTP id p6so3844050plo.6 for ; Thu, 10 Dec 2020 18:32:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mtcc.com; s=fluffulence; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=P/uORwSKuvG1jUt9CY55viobJTxV7Vjt+xnJOZbbeeE=; b=JWVA1rKiQWKNy6UkSW9yVj5j03CQqzCF6O9DV77qAp5DTHz+KJMOYdJdPa+HBAOWMo rZlRjnPucwwatDISuyj7+MT4vch6sVz+nffZlh/OG+X6HTFvePUeBE5Vz7aT58FL8ZvE VdOdmjWfMVmBMxtD8SX6VQE9efd7IM3DX8yY3RLrYmj+Q7gBtxKQIBMVkYY63p2M9S5a jqgl49MCxCcn3teu2V3fH2L6ybZqr8ZaJLd1OuRcgjXZmWiB8jJuyM7wPT6v93q/Pl23 RcMvbB80xe3dohjD6G+Me493xrQI00MR3cO0RhisluTUcMXNLyrt5bebtKYYFKXRy7id BQOQ== 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=P/uORwSKuvG1jUt9CY55viobJTxV7Vjt+xnJOZbbeeE=; b=Kpx9Z4zA2KUHQ/THbYSxgREIk8cP/77qEl6jgI9FZmIoQcKk9ItVvALd6iyrfHUzpu vzaE3AF5a8cNiw2uQVmN6YiuCH0xHEoU1/HQZc3QpuFFiuqKQZGA5nmCMjAyHxq8yMOU JBLZ8en1cw14jLeRAXZkm1+L5MAuLRGdmbFPxrm/ic8gTgt2dAwDfe8TtRG0HWPAAJy6 Hi89kzMx61KZFVCQQZAvDoRrv5Z1UZ0uhhrNPX8maHqzkBw6PCblM/ijBlO39N5X+61i NrpKgTUmbNnHqQ8TFA476w1bhzx0vZ1VzKtLQjLcfhIuxNVPq4gNQ2sLZxti9HniTLpq sf2g== X-Gm-Message-State: AOAM531h+VMOs2GImfTyeCrox5zkMomVVxGFnLZ7bWUCTChXE1iNwAaV ehczP0GgW/n14m0ppAxM1VsYrXhH8aCb6w== X-Google-Smtp-Source: ABdhPJwh/tK7BMe7OcXUx4cdA5lf44rreeiJA3EcZ6F0oTSahBo9Tz0DWuVQkEUBqycVmC4h42NCog== X-Received: by 2002:a17:902:900a:b029:d7:d966:1a44 with SMTP id a10-20020a170902900ab02900d7d9661a44mr9148685plp.8.1607653971245; Thu, 10 Dec 2020 18:32:51 -0800 (PST) Received: from mike-mac.lan (107-182-41-154.volcanocom.com. [107.182.41.154]) by smtp.gmail.com with ESMTPSA id 77sm7391897pfx.156.2020.12.10.18.32.49 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 10 Dec 2020 18:32:50 -0800 (PST) To: Dave Crocker , dmarc@ietf.org References: <923de33f-3707-facf-389e-371f6ee64008@gmail.com> <16B0B820-7080-4937-8642-3A6B84B441AA@gmail.com> <1f5b3e62-e6f4-0bc2-221e-362667536727@gmail.com> <07bdeba8-639e-f05f-6981-d4f59040612f@gmail.com> From: Michael Thomas Message-ID: <4e53e941-59e7-c0ac-fdf8-69ccc02948ba@mtcc.com> Date: Thu, 10 Dec 2020 18:32:48 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 MIME-Version: 1.0 In-Reply-To: <07bdeba8-639e-f05f-6981-d4f59040612f@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] p=quarantine X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 11 Dec 2020 02:32:54 -0000 On 12/10/20 6:28 PM, Dave Crocker wrote: > On 12/10/2020 6:25 PM, Michael Thomas wrote: >> I think this all should be driven by "what are you asking me to do?" > > The domain owner has no business asking the receiver to do anything.  > The receiver has no relationship with the domain owner. > > However, the receiver might like to hear the domain owner's opinion > about usage of the domain when DMARC fails.  But that's different from > attempting to give direction to the receiver (who demonstrably will > ignore that direction and make their own decision.) > Semantic nit picking at best. If the receiver doesn't care about the sender's opinion, they don't need to implement DMARC. Manifestly they do have a stake in what the sender's opinion is if they deploy DMARC. The only question is whether DMARC captures those opinions correctly. Mike From nobody Thu Dec 10 18:44: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 AB94B3A0115 for ; Thu, 10 Dec 2020 18:44:22 -0800 (PST) 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 83CcUI-IvI46 for ; Thu, 10 Dec 2020 18:44:21 -0800 (PST) Received: from mail-pj1-x1032.google.com (mail-pj1-x1032.google.com [IPv6:2607:f8b0:4864:20::1032]) (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 A52743A0100 for ; Thu, 10 Dec 2020 18:44:21 -0800 (PST) Received: by mail-pj1-x1032.google.com with SMTP id b5so56946pjk.2 for ; Thu, 10 Dec 2020 18:44:21 -0800 (PST) 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=L8V1i3+1cdhoZc2bN0t1soUkb40jCseK2F6LQGU1RPQ=; b=o2Y9Rc9Z9mUmCz42b+xoO/zlDXTU5AlYdOXW3tICGdloJtzQxXWMGotxpk0Mw0Basf MiVpqf37+7+BNJVSnKva8C9q2iHKyN+xG6wP65qcGG8Iy18UySsuommXMD8LGCAHlZZU czZPnQWjaXL/7YNN8jYplePiclkK1uuZzbb00k0k9X3OIQtd3eH1XaHjdS17w2l5NYTv eL+p3Xm1p+hXUZoKtJBY2f11f/aOtsNm5pXck7q/91CVVCe6T4xOk4PnkUIR36F44Xoe YchpKQnHDiJnWXCgeHuoBkc1g0CWIRhAMDbG62e6s/FrHThpfbtXfEIrEQN+biWUl9J4 MLvw== 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=L8V1i3+1cdhoZc2bN0t1soUkb40jCseK2F6LQGU1RPQ=; b=plBH2iRviiy6LX9xBzN5myHulsIcswMF4C9ZdIzk9A3BO/+mjdEF5aJ1yf0dYp6pZj jU7+g2n7mIjg3WoCkIDGpKnvaD/NZfJ6dNRNPVTWSOYIhhcWr5VIb0eQeXBcrrXUC95B /uWIJprXiymrhMZfWSzhqFghbO4ZA6JFgbSpDJv9vu2mYP8z4fVHU/9HGIDqXO/r5OZ/ 3oXHISKE7a3XLWgd8z/iCG9xqnwT04P4EooE3pL5tKIgnGJVAapvDvKxBKlgAwfCy/s7 KV7wgeoDnTyTbP1IpidAK74Ghxx5NhQijsyYcr6Hzzk38dZWGJRC/WG1XKYrAc/qi+FO geGw== X-Gm-Message-State: AOAM531+SSs11OogmmoG9sQykcwfi+Uk4DJ6V6dhiRTMY8OzqkIZxq1s SFGlN1BBCTvgi2HUFoKh0cCbGMoFAEs= X-Google-Smtp-Source: ABdhPJwat571MUT/f1LI3FPzB19kxV8tWMepoKrLQtq6zuEKVWi+M/G/MTV5x/D24xBNzsSsqHaeLg== X-Received: by 2002:a17:902:9f97:b029:da:357b:22b0 with SMTP id g23-20020a1709029f97b02900da357b22b0mr8999862plq.73.1607654660896; Thu, 10 Dec 2020 18:44:20 -0800 (PST) Received: from [192.168.0.109] (c-24-130-62-181.hsd1.ca.comcast.net. [24.130.62.181]) by smtp.gmail.com with ESMTPSA id 24sm9006155pgy.45.2020.12.10.18.44.19 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 10 Dec 2020 18:44:20 -0800 (PST) To: Michael Thomas , dmarc@ietf.org References: <923de33f-3707-facf-389e-371f6ee64008@gmail.com> <16B0B820-7080-4937-8642-3A6B84B441AA@gmail.com> <1f5b3e62-e6f4-0bc2-221e-362667536727@gmail.com> <07bdeba8-639e-f05f-6981-d4f59040612f@gmail.com> <4e53e941-59e7-c0ac-fdf8-69ccc02948ba@mtcc.com> From: Dave Crocker Message-ID: Date: Thu, 10 Dec 2020 18:44:19 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.5.1 MIME-Version: 1.0 In-Reply-To: <4e53e941-59e7-c0ac-fdf8-69ccc02948ba@mtcc.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] p=quarantine X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 11 Dec 2020 02:44:23 -0000 On 12/10/2020 6:32 PM, Michael Thomas wrote: > Semantic nit picking at best. Because semantics do not matter in a specification? d/ -- Dave Crocker dcrocker@gmail.com 408.329.0791 Volunteer, Silicon Valley Chapter American Red Cross dave.crocker2@redcross.org From nobody Thu Dec 10 18:53:12 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBC343A13E7 for ; Thu, 10 Dec 2020 18:53:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.751 X-Spam-Level: X-Spam-Status: No, score=-1.751 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, 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=mtcc.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 GIgC_k8CGraS for ; Thu, 10 Dec 2020 18:53:09 -0800 (PST) Received: from mail-pj1-x102d.google.com (mail-pj1-x102d.google.com [IPv6:2607:f8b0:4864:20::102d]) (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 D73D93A13D8 for ; Thu, 10 Dec 2020 18:53:09 -0800 (PST) Received: by mail-pj1-x102d.google.com with SMTP id z12so1467256pjn.1 for ; Thu, 10 Dec 2020 18:53:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mtcc.com; s=fluffulence; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=umvxmjeAHt14UWOfmb6WaLUbsa8TlunbpDKDGm1ZGg8=; b=jlxYF77i0i5OVs7qMBkL1Y46LYK1CQtA6gsa9rhpNAFl/56wKZqVIcjxo590qkpzjp uXHLGb2vXFpuRkEPeVR50PQ9QSeEn2YqCLdKQalCyNC0f/1759/NAquBPtakUjMJvP28 s6axOuVB5tVBy7toOy9V313O6zOcvvEeKXrX2LfYF3MAMzTQ3ypEVqUpxCVeVqvJdWP1 PcGVJdVNc2nlsGYqYdKJ9bra2RXeEyuLhuFLu/OpXdeshmDnZvTnGRY5MOtU+yEljm49 Uq1V9bJXC8YxafldVuvVrudWGzaHz9Zh1J7z0mE1HcCUb1TKjc9mLzSzxsUeO6c2H6av FbNQ== 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=umvxmjeAHt14UWOfmb6WaLUbsa8TlunbpDKDGm1ZGg8=; b=dUvdL3dE5pmOCzLauZJWJ1iGImjUuHo21af7IlyaAS+TZapb8pa7z7A8Ti+cfd8QAd mC55EnXMollVblPzBBOfYR1z6v4oQV23+vnuDs1z5xptpA+fYT6oXpy9GNVYzA/fKavP Cr4hR/tUEqsB3aKQlsFN0gn/vIfZHVxpwMGew8LKeDEvQW0ap2kqCxO+KrS432yBU/pz mQx5KJ6Gb4hoPsltnJhHOGWQylPgsDv47FNDNgo4Snb0vHY0HeqQZzdL+yg5OW698jXk WFyBLYnFjlek3TaNkTvXaRbAXq8xSH4ahwcVwPdun1S7V8mNtrgpTjsM618hUBtcDAsY UgaQ== X-Gm-Message-State: AOAM533sALq9qJZQydpZXamSmQn+3dHc7qnjO9r6vWrOtcZQFjMW51fT PYDKuUfoWweVAm7B/q4a4e4v48RYdUqDGw== X-Google-Smtp-Source: ABdhPJxMEkgXpft0uWWfSj8RDKCLPdNpr79r/AgnPQolBJyyyCGR+RZ5lKdLeNPfbGlAlWLFzjTRFQ== X-Received: by 2002:a17:90a:db0b:: with SMTP id g11mr7660180pjv.168.1607655188874; Thu, 10 Dec 2020 18:53:08 -0800 (PST) Received: from mike-mac.lan (107-182-41-154.volcanocom.com. [107.182.41.154]) by smtp.gmail.com with ESMTPSA id v24sm7916305pgi.61.2020.12.10.18.53.07 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 10 Dec 2020 18:53:08 -0800 (PST) To: Dave Crocker , dmarc@ietf.org References: <923de33f-3707-facf-389e-371f6ee64008@gmail.com> <16B0B820-7080-4937-8642-3A6B84B441AA@gmail.com> <1f5b3e62-e6f4-0bc2-221e-362667536727@gmail.com> <07bdeba8-639e-f05f-6981-d4f59040612f@gmail.com> <4e53e941-59e7-c0ac-fdf8-69ccc02948ba@mtcc.com> From: Michael Thomas Message-ID: <1692020a-11c2-9d88-d315-857a344fc30e@mtcc.com> Date: Thu, 10 Dec 2020 18:53:06 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.5.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] p=quarantine X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 11 Dec 2020 02:53:11 -0000 On 12/10/20 6:44 PM, Dave Crocker wrote: > On 12/10/2020 6:32 PM, Michael Thomas wrote: >> Semantic nit picking at best. > > Because semantics do not matter in a specification? > > It's ok, I guess but I wouldn't want to make a career of nit picking. It's a lot more useful to get intent across of what the actual intent is rather than trying to express what is ultimately a code point for a filter that doesn't care about the ascii string. Mike From nobody Fri Dec 11 05:48: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 C55BB3A0C06 for ; Fri, 11 Dec 2020 05:48:13 -0800 (PST) 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 tIDDGLoXYVdk for ; Fri, 11 Dec 2020 05:48:12 -0800 (PST) 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 655613A0C04 for ; Fri, 11 Dec 2020 05:48:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1607694489; bh=zOpJ2hSP/nZNNelqPsgkdiOWOpow5AQlcEchN7pzYWI=; l=3270; h=To:References:From:Date:In-Reply-To; b=DQ3+FDH2r54OR+Q0DFV0n+wobkRmjuFV1mjV9bsxRJXGpUxmOrBWpd4bvs2q6VPOc Ni8qoRADpXtfQ2fQ0QQGwV8jSybNtLQ/JlbNhA0AFg97Tc4YHolEYmK9IF4XZqLZYc 6mbOaZrlld/PlmLAYS/gYFIDtPrcwpjr89Da3HGHa7MmfDI3IVlcneBCrWReO Authentication-Results: tana.it; auth=pass (details omitted) Original-From: Alessandro Vesely 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.000000005FD37899.00000DE3; Fri, 11 Dec 2020 14:48:09 +0100 To: dmarc@ietf.org, Jesse Thompson References: <609e1c9b-cc4d-d7d1-0fa8-79f515c1eee4@tana.it> <20201209185246.1D40C29474C4@ary.qy> From: Alessandro Vesely Message-ID: <747eae71-24e7-fd05-2123-2c22ae4588e8@tana.it> Date: Fri, 11 Dec 2020 14:48:09 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Ticket #61 - Define and add a simplified (redacted) failure report X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 11 Dec 2020 13:48:14 -0000 On Thu 10/Dec/2020 17:59:54 +0100 Jesse Thompson wrote: > On 12/9/20 10:28 PM, seth wrote: >> As an individual, I feel extremely strongly that failure reports should go away in their entirety. Although Jesse Thompson has outlined a use case that really has no other good solution, and is equally true in other large complicated organizations. > > To be clear, I'm not advocating for this From/To use case, but I know of universities who would. There's at least one who cleverly flattened their SPF record to include every known sender specifically because they had no mission to change the way their institution distributively sends email. That is the type of organization who *may* want From/To data, assuming they want to do more validation before adding yet another IP to their SPF. It's a stretch in my mind. I'm not clear whether you're talking about sending or receiving reports. Received: chains are key for evaluating addresses to add to SPF records. I don't think it makes sense to specify their omission from My guess at why an organization may want to send only From/To rather than a possibly redacted text/rfc822-headers are as follows: * It is too hard for them to asses the risk of including unknown header fields, yet they must do it before enabling ruf, * the software they use doesn't have an option to redact PII, or (unlikely) * they try to save bandwidth and disk space by reducing that ghastly pile of freaky fields that infest message headers these days. > I would only strongly advocate for seeing the unredacted From header, since my primary concern was with identifying a little bit more information about who was using the domain and why (i.e. who is using random ESP). Agreed. > The stated purpose of Failure Reports is "for quickly notifying the Domain Owners when there is an authentication failure ... also provide more information about the failed message than is available in an aggregate report". Since the focus of DMARC is to authorize the use of the domain used in the From header, then the logical next incremental levels of "more information" should be: > > 1) From header domain (already known) > 2) local part of From address > 3) Friendly From > 4) Subject > 5) other parts of the message containing identifiable information > > 1->5 decreases in usefulness/relevancy to DMARC > 1->5 increases in unnecessary information disclosure The mail filter I do sends aggregate reports but not failure reports. Should I add it? I'm thinking I could frame it like so: * Have a global flag to enable or disable ruf's, which can be overridden on a per-domain basis. Default to disabled. * The flag can specify three confidentiality levels: - full message - header only - header only + redact. * Redacting the header would work as follows: 1. Collect recipients addresses in To:, Cc:, and envelope, 2. compute the rfc6590-redacted version of each address, 3. for all fields, replace any occurrence with the redacted version. * Reports are left in a user-configured directory, assuming that a user supplied script deals with them. Does that make sense? Should dmarc-failure-reporting include text with practical suggestions along those lines? Best Ale -- From nobody Fri Dec 11 08:11: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 9F31F3A0CEB for ; Fri, 11 Dec 2020 08:10:59 -0800 (PST) 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=QT6hGwFg; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=UgZc3Awr Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1hlvsnj3oVNm for ; Fri, 11 Dec 2020 08:10:57 -0800 (PST) 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 20C573A0CEA for ; Fri, 11 Dec 2020 08:10:56 -0800 (PST) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha256; c=simple/relaxed; l=4120; t=1607703051; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=KZZbd110SxH7k5sO35/J0Td3Eqpe uCv9hHeW9EedW6w=; b=QT6hGwFgkQQRLY0yr7mtTUZOFh20V2VHn7x0vODwNhN1 bBeUBw6l2lwfSPt+k2LO5RKX2BZrIpp+XtifAHjhPLVLsYktHUHXVtviA/+Q/0QT u9FgHT8HJrAxWPdBfYg4F2hvRBHT7rW/EfNB4Rokm/otVaGCKqPRYw8w7fra+aw= Received: by mail.winserver.com (Wildcat! SMTP Router v8.0.454.10) for dmarc@ietf.org; Fri, 11 Dec 2020 11:10:51 -0500 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 1143134223.6153.1260; Fri, 11 Dec 2020 11:10:51 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=4120; t=1607702710; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=KZZbd11 0SxH7k5sO35/J0Td3EqpeuCv9hHeW9EedW6w=; b=UgZc3AwrA9cq+UzQN4uNSf1 bOd+CP6j+ebwb5LBqMZpuGwqHz4JQmYKAa8Ng4OcIJTUBY/kGIipGMjk8YqBQX47 0BwfMi0Nm+DG9a7G2OK3kaBWcD+GZsGEM4WEHf+hI4M95O2SuArDF5fyjztcc95+ xGrJ2x5RGPLljDXP6zlU= Received: by beta.winserver.com (Wildcat! SMTP Router v8.0.454.10) for dmarc@ietf.org; Fri, 11 Dec 2020 11:05:10 -0500 Received: from [192.168.1.68] ([75.26.216.248]) by beta.winserver.com (Wildcat! SMTP v8.0.454.10) with ESMTP id 1010014439.1.2976; Fri, 11 Dec 2020 11:05:09 -0500 Message-ID: <5FD39A0E.5000300@isdg.net> Date: Fri, 11 Dec 2020 11:10:54 -0500 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 , "Kurt Andersen (b)" CC: IETF DMARC WG References: <923de33f-3707-facf-389e-371f6ee64008@gmail.com> <16B0B820-7080-4937-8642-3A6B84B441AA@gmail.com> <1f5b3e62-e6f4-0bc2-221e-362667536727@gmail.com> <8e0ff141-2842-606c-91e9-e588edab7ef1@gmail.com> In-Reply-To: <8e0ff141-2842-606c-91e9-e588edab7ef1@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] p=quarantine X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 11 Dec 2020 16:11:00 -0000 On 12/10/2020 9:26 PM, Dave Crocker wrote: > On 12/10/2020 6:01 PM, Kurt Andersen (b) wrote: >> I think that is much closer to the right semantic but highlights a >> problem that the mail coming from a particular domain probably >> doesn't rate a single broad-brush characterization of seriousness. > > I've assumed the none, quarantine, reject choices are meant to > indicate just how certain the domain owner is that the mail is > problematic. > > Perhaps: >+ > none: not certain at all > > quarantine: I believe I've got control of all my sending, but am > not 100% positive > > reject: I have control of all my sending; if it doesn't pass > DMARC, it's use of the domain is bogus. When it comes to keeping focus with the purpose of SPF and DKIM-POLICY protocols and its implementation out of the box, default behavior: 1) The main purpose is Receiver Abuse Control. 2) Special attention to Port 25 Unsolicited Anonymous Senders and Message Authors. 3) For authenticated, authorized, white listed clients, SPF and DKIM do not apply, mail is always accepted. Hard policies with SPF and DKIM-POLICY are honored aggressively. Softer policies are processed, classified and passed through to next filters, if any remaining, i.e. GreyListing. * SPF -ALL, REJECT - Receiver rejects at MAIL FROM state with a 550 response. * ADSP DKIM=DISCARDABLE, Receiver rejects at SMTP DATA state with a negative 550 DATA response. * DMARC p=reject, Receiver rejects at SMTP DATA state with a negative 550 DATA response. * DMARC p=quarantine, Receiver accepts at SMTP. Mail is moved outside targeted users' main inbox mail stream, i.e. can not be picked up by user's POP3 or normal mail pickup process. The user has to login in online to see the mail in another non-inbox folder, i.e. spam box. Thats it. No reporting. Period. The domain should be grateful their public mail policy instructions is being honored for strict operations at compliant receivers. I hope their compliant receivers are also honoring our strict public mail policies as well to help protect fraudulent usage. I really do not need a report for the expected action when fraudulent mail is detected. Overall, the receiver is doing the domain a favor by helping them protect their domain reputation from possible fraudulent usage of their domains, and at the same time, it is helping its own system and the target hosted user from potential abuse as well -- a win win situation. For List-related situations, the receiver follows the 2006 DSAP recommendations: https://tools.ietf.org/html/draft-santos-dkim-dsap-00 1) If a new subscribing domain has a restrictive public mail policy with ADSP and/or DMARC, the subscription is denied. 2) Incoming messages are checked for mailing list destinations. If the submitter's domain have restrictive public mail policies with ADSP or DMARC, the submission is rejected with a 550. With these two simple peripheral filters, there was no need to modify the legacy list server source code for Rewriting or anything else related to the "in-direct" mail problem. The DMARCbis codification/changes I am looking for are: 1) Improvements in the DNS lookup algorithm, optional additional lookups should be provided or referenced. 2) Recognition and support for ATPS to cover 3rd party authorization. and other fine tunning, clarifications, for example, in another thread, it was stated: "When you switch to p=quarantine pct=0, no one should apply quarantine (so it's equivalent to p=none)," I thought the "pct=" was related to when reporting should be applied. I apparently read it wrong. This needs to be code reviewed and corrected on our end, if needed. We are not doing reporting at this time. Not the main focus. That can come later as an augmented feature, in fact, we might consider it as a paid service to be sending thousands report out to domains. Keep it simple folks. Be safe and have a great weekend. Thanks -- Hector Santos, https://secure.santronics.com https://twitter.com/hectorsantos From nobody Fri Dec 11 08:19: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 7DA843A0CED for ; Fri, 11 Dec 2020 08:19:53 -0800 (PST) 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 Fpj7ldyHbVD6 for ; Fri, 11 Dec 2020 08:19:52 -0800 (PST) Received: from mail-qt1-x833.google.com (mail-qt1-x833.google.com [IPv6:2607:f8b0:4864:20::833]) (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 3BF5C3A0CEC for ; Fri, 11 Dec 2020 08:19:52 -0800 (PST) Received: by mail-qt1-x833.google.com with SMTP id a6so6790609qtw.6 for ; Fri, 11 Dec 2020 08:19:51 -0800 (PST) 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=NDW9A4SDw7Hsp/AWDqOp6tobcBqxTck7HSbWayFfIQ4=; b=UeIOnywzZaCPfZpKjyvnnhzpFaAs7s0l5mEUkwCWQSKqKOpDtCL9B5deW4u3enfDlh X+T2kb2jgFEn61UdTQt/GrU1wOPOr+hQY/4dm8EdpuasGOHfHsr3IrYJPs0d2nPVsuYV 7vLCJJ0de46Qd8lq3PUZpc+2iLTZ4VpdjK46WA4KgVJo56zDjUUSGJkx0K/GrgUV4gOt R4WtYJc5d4n5h56e04yUysNG5sX4xAE6Cnv2NcIUAMKyeCqDOFbZhot+2Gi9NVQSrhsz Cm6JdAMq63ICPuwrM0M1ycrcNrthfMfXtzYZnHTNbusRgZ4Ev/NqKoCgqKruIyll1TpS lLWA== 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=NDW9A4SDw7Hsp/AWDqOp6tobcBqxTck7HSbWayFfIQ4=; b=rMNf67RArqcuLedv2T8uiA86cEPE7NGoKsRStkQQC+eMLiS117TUWNgmWYiEsxhw2Z nXbi+ypNIOdhPFeU4EfOu5Q2LSTClxFwPzvb5bmYnASocjRWP55SsP7+vIrFzrINSFjP CnBHKy0NBWWjCLSTN9yvFYwnvFijN/9938oAfSkkA2cA22K8vTMLK2NIWm+M0BSSsrCK U2q9It/M/ufXVaLDHkrgkHAy5GRIKiDZyxnuo9FtDvP0IQ6Jq8iaDGcWtHZJCHI8H3Wq Ow71mPnRz92Hhi46tB4XjhzHwli0dmXU6Ekk0CMbUtvPgmhCH/4fu62b1FTkMfJNp9gk DxKQ== X-Gm-Message-State: AOAM531Nuby5LiIDVnUHUn+7dyYlt7HY1zwwNak433WBFFgiBqhFc/b4 K+0Xc9CNAkfBKSLrLtviSW1cxLyce0nctT717Os= X-Google-Smtp-Source: ABdhPJxa4vsP+4ZsuU3KvoxTFVBdNJZQ04PXZas1/Rp4QdbHCol+CjFBQ1wHLacoWCfQ+hlr5nFvkyCZoDnWLEeTwio= X-Received: by 2002:ac8:5d53:: with SMTP id g19mr16612292qtx.354.1607703591042; Fri, 11 Dec 2020 08:19:51 -0800 (PST) MIME-Version: 1.0 References: <923de33f-3707-facf-389e-371f6ee64008@gmail.com> <16B0B820-7080-4937-8642-3A6B84B441AA@gmail.com> <1f5b3e62-e6f4-0bc2-221e-362667536727@gmail.com> <8e0ff141-2842-606c-91e9-e588edab7ef1@gmail.com> <5FD39A0E.5000300@isdg.net> In-Reply-To: <5FD39A0E.5000300@isdg.net> From: Dotzero Date: Fri, 11 Dec 2020 11:19:38 -0500 Message-ID: To: Hector Santos Cc: Dave Crocker , "Kurt Andersen (b)" , IETF DMARC WG Content-Type: multipart/alternative; boundary="00000000000072c4af05b632a914" Archived-At: Subject: Re: [dmarc-ietf] p=quarantine X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 11 Dec 2020 16:19:54 -0000 --00000000000072c4af05b632a914 Content-Type: text/plain; charset="UTF-8" On Fri, Dec 11, 2020 at 11:11 AM Hector Santos wrote: > We are not doing reporting at this > time. Not the main focus. That can come later as an augmented > feature, in fact, we might consider it as a paid service to be sending > thousands report out to domains. > That's good community spirit. I doubt many would be willing to pay you for your reports. Michael Hammer --00000000000072c4af05b632a914 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Fri, Dec 11, 2020 at 11:11 AM Hect= or Santos <hsantos=3D40isdg= .net@dmarc.ietf.org> wrote:
We are not doing reporting at this
time.=C2=A0 Not the main focus.=C2=A0 That can come later as an augmented <= br> feature, in fact, we might consider it as a paid service to be sending
thousands report out to domains.

That&#= 39;s good community spirit. I doubt many would be willing to pay you for yo= ur reports.

Michael Hammer
--00000000000072c4af05b632a914-- From nobody Fri Dec 11 08:30: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 549A83A0CFF for ; Fri, 11 Dec 2020 08:30:09 -0800 (PST) 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=ffeM+Cxt; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=mvcokytH Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O8q30W8WQ1E8 for ; Fri, 11 Dec 2020 08:30:07 -0800 (PST) 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 CD6C83A0CFA for ; Fri, 11 Dec 2020 08:30:06 -0800 (PST) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1212; t=1607704201; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=Sa+J+ECM1jO/NUdROFiWg2XkrT8Y o/l91BVJumqSE9s=; b=ffeM+CxtTZcM7fNPDRc2qd31yqlSzTASjDsXaYfAEdtp Q3pGx+cM749RHtxY1db7KMS/UvRlBntHmGBf39w5XD2/fgZAvyVrEo6ad87C44Ro uGpLkvPB+N6FklMWMCbdMfSLDDJaThAIQgM9BUBEAIdfur9gP6afgWiuM9jWsS8= Received: by mail.winserver.com (Wildcat! SMTP Router v8.0.454.10) for dmarc@ietf.org; Fri, 11 Dec 2020 11:30:01 -0500 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 1144284418.6153.3936; Fri, 11 Dec 2020 11:30:01 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1212; t=1607703859; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=Sa+J+EC M1jO/NUdROFiWg2XkrT8Yo/l91BVJumqSE9s=; b=mvcokytHtwk+Eu3Yl+aXQ+O AjinVhPZmivbbvURw2u4TPxm2cngLL5rCmyvSdsFY2rEmNrd9plVLfzBsu7PrJpx ViytRISjEkZb5uwQLZnU6dN1A9N3kzPiDorpy8j58OvuOPE1nB5Y8qPzzum1APqQ rLvF8XAzz4U+m35UB5yQ= Received: by beta.winserver.com (Wildcat! SMTP Router v8.0.454.10) for dmarc@ietf.org; Fri, 11 Dec 2020 11:24:19 -0500 Received: from [192.168.1.68] ([75.26.216.248]) by beta.winserver.com (Wildcat! SMTP v8.0.454.10) with ESMTP id 1011164267.1.16904; Fri, 11 Dec 2020 11:24:19 -0500 Message-ID: <5FD39E8C.4060302@isdg.net> Date: Fri, 11 Dec 2020 11:30:04 -0500 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: <923de33f-3707-facf-389e-371f6ee64008@gmail.com> <16B0B820-7080-4937-8642-3A6B84B441AA@gmail.com> <1f5b3e62-e6f4-0bc2-221e-362667536727@gmail.com> <8e0ff141-2842-606c-91e9-e588edab7ef1@gmail.com> <5FD39A0E.5000300@isdg.net> In-Reply-To: <5FD39A0E.5000300@isdg.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] p=quarantine X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 11 Dec 2020 16:30:09 -0000 On 12/11/2020 11:10 AM, Hector Santos wrote: > * SPF -ALL, REJECT - Receiver rejects at MAIL FROM state with a 550 > response. Correction: * SPF -ALL, REJECT - Receiver rejects at RCPT TO state with a 550 response. SPF is only tested once a valid (existing) RCPT TO is provided. This was the very first major optimization done with SPF back in 2003/2004 when it was first changed from MAIL FROM to RCPT TO. It resulted in a DNS lookup overhead savings of 60% because at the time, 60% of the RCPT TO were "unknown, not locally hosted" addresses. This mode of operation is on-par with the SMTP RFC5321 Section 3.3 recommendation: 3.3 Mail Transactions ..... Despite the apparent scope of this requirement, there are circumstances in which the acceptability of the reverse-path may not be determined until one or more forward-paths (in RCPT commands) can be examined. In those cases, the server MAY reasonably accept the reverse-path (with a 250 reply) and then report problems after the forward-paths are received and examined. Normally, failures produce 550 or 553 replies. -- Hector Santos, https://secure.santronics.com https://twitter.com/hectorsantos From nobody Fri Dec 11 08:32: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 DA34E3A0D04 for ; Fri, 11 Dec 2020 08:32:49 -0800 (PST) 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 eZjL_7dkjE4N for ; Fri, 11 Dec 2020 08:32:48 -0800 (PST) Received: from mail-io1-xd36.google.com (mail-io1-xd36.google.com [IPv6:2607:f8b0:4864:20::d36]) (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 7B1693A0CF8 for ; Fri, 11 Dec 2020 08:32:48 -0800 (PST) Received: by mail-io1-xd36.google.com with SMTP id o8so10087927ioh.0 for ; Fri, 11 Dec 2020 08:32:48 -0800 (PST) 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=UIJLrNAJ716u0unKTJdRnIY5qCJ7L5TSXXEvlMWtN78=; b=NwqQiVf+yNu/c8Gb1j5At1i7zfCYxwo+5BAHn7Lv0GyGdhkSHqi+4fmQsoR37uvT5x qFDKKn5RN0sO9NVmr5GWW3f5xdvSm4WFe8vQO5D+VCElFTF41+JnDBYkkjPvNqkKXxoD zurOExvfquQQq7kqqO8eE8adQa873EZ5zY6pU= 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=UIJLrNAJ716u0unKTJdRnIY5qCJ7L5TSXXEvlMWtN78=; b=jGbSF6eLmfYSiN8XUR+Z5yCN1qw6NO+42fJ9/qJwOVBzwiozjfXpvikbpzcVk2xtUt Ds/bT35I/5uj1mA0cUG/w8MAvCA8z368sZGEn1cfTsHajp8m1f8F+gIqmv1u8HmPYAcB mlUS/8i8eK3RvoaQmb3JCc/k5liD9MrJYODNIlm1wZo9cQA9pGxWcPLxgmLG/J7+vpaY Mj4EdBgu98xZmMFr9tOgVaL+pIcNNiY7QDNOoZKtiFkrti0Ug2QMWmB1eHwVL9cLohYy UQFw6+lxS9w4kSIh8zwDc7w4h8Xj7kizcTpsw2oViS0bQP2THOddsxK7qAALN8+lz18b 2mCA== X-Gm-Message-State: AOAM531HNVUABSROrHWlaWfg3kbJPLLrla7jIDt9jsO4bgpISPrneK6A VW4sDq+qP8xJK5DafdIyvQ14NdFS0kgKZoAe0nLzxg== X-Google-Smtp-Source: ABdhPJy78pd9DNO9bfMnjfpAaXWDzHex/Z3GE/rJvgYQK/No1xfZjhzVA+wYGvRg+zwboiXwAikWRCFuBGtDKUks6Ug= X-Received: by 2002:a02:9f8b:: with SMTP id a11mr17058554jam.108.1607704367595; Fri, 11 Dec 2020 08:32:47 -0800 (PST) MIME-Version: 1.0 References: <923de33f-3707-facf-389e-371f6ee64008@gmail.com> <16B0B820-7080-4937-8642-3A6B84B441AA@gmail.com> <1f5b3e62-e6f4-0bc2-221e-362667536727@gmail.com> <8e0ff141-2842-606c-91e9-e588edab7ef1@gmail.com> In-Reply-To: <8e0ff141-2842-606c-91e9-e588edab7ef1@gmail.com> From: "Kurt Andersen (b)" Date: Fri, 11 Dec 2020 08:32:34 -0800 Message-ID: To: Dave Crocker Cc: IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000bc199705b632d71c" Archived-At: Subject: Re: [dmarc-ietf] p=quarantine X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 11 Dec 2020 16:32:50 -0000 --000000000000bc199705b632d71c Content-Type: text/plain; charset="UTF-8" On Thu, Dec 10, 2020 at 6:26 PM Dave Crocker wrote: > On 12/10/2020 6:01 PM, Kurt Andersen (b) wrote: > > I think that is much closer to the right semantic but highlights a > > problem that the mail coming from a particular domain probably doesn't > > rate a single broad-brush characterization of seriousness. > > I've assumed the none, quarantine, reject choices are meant to indicate > just how certain the domain owner is that the mail is problematic. > > Perhaps: > > none: not certain at all > > quarantine: I believe I've got control of all my sending, but am > not 100% positive > > reject: I have control of all my sending; if it doesn't pass DMARC, > it's use of the domain is bogus. > But the problem case in our off-topic rabbit trail meanderings is that people who "have control of all their sending" still don't necessarily send mail of consistent seriousness nor do they have any control of the paths by which that mail takes to get to the ultimate recipient. There is a conflation of "control of emission" with "control of path". --Kurt --000000000000bc199705b632d71c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Dec 10, 2020 at 6:26 PM Dave Croc= ker <dcrocker@gmail.com> wr= ote:
On 12/10/2020 6:01 PM, Kurt Andersen (b) wrote:
> I think that is much closer to the right semantic but highlights a > problem that the mail coming from a particular domain probably doesn&#= 39;t
> rate a single broad-brush characterization of seriousness.

I've assumed the none, quarantine, reject choices are meant to indicate=
just how certain the domain owner is that the mail is problematic.

Perhaps:

=C2=A0=C2=A0=C2=A0=C2=A0 none: not certain at all

=C2=A0=C2=A0=C2=A0=C2=A0 quarantine: I believe I've got control of all = my sending, but am
not 100% positive

=C2=A0=C2=A0=C2=A0=C2=A0 reject: I have control of all my sending; if it do= esn't pass DMARC,
it's use of the domain is bogus.

Bu= t the problem case in our off-topic rabbit trail meanderings is that people= who "have control of all their sending" still don't necessar= ily send mail of consistent seriousness nor do they have any control of the= paths by which that mail takes to get to the ultimate recipient. There is = a conflation of "control of emission" with "control of path&= quot;.

--Kurt=C2=A0
--000000000000bc199705b632d71c-- From nobody Fri Dec 11 08:59: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 2B1033A0CD4; Fri, 11 Dec 2020 08:59:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.233 X-Spam-Level: X-Spam-Status: No, score=-1.233 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=messagingengine.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 jXviH_Hj_P8w; Fri, 11 Dec 2020 08:59:37 -0800 (PST) Received: from forward4-smtp.messagingengine.com (forward4-smtp.messagingengine.com [66.111.4.238]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6019D3A0D25; Fri, 11 Dec 2020 08:59:37 -0800 (PST) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailforward.nyi.internal (Postfix) with ESMTP id 2EDFD194392C; Fri, 11 Dec 2020 11:59:36 -0500 (EST) Received: from imap21 ([10.202.2.71]) by compute2.internal (MEProxy); Fri, 11 Dec 2020 11:59:36 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=WYSbhf 4pBboQyfptO9NRACh8rG/BiEXFvd/UDmp8Mjc=; b=IGWZa5h4uJPoj9fsoqbl6T oYhTHlOEua9eeSKVnPGycbbOJgYn7Lo4fFIlqJCkJ5u8YFOHGsWHQH7BH/cUvErC jdfBHljlbdtXWg4VFQaqZaN+iteRIhgGU6ISqG+xbb9nni85j+ZjzihSUMg28m92 dfRO3c5oiuAKLlVrnjVDjWcXgeUtUSoCWSkMFkkSSqr3TtmVQpHBpv6gMpIuQdLm Fdy9TMTY70ndD8s4+q7ov8JkIfa4k7bcGCOD2bFxBP/R/3jJG5NFc7Iu+2Poaenf QMzhUYUotnK6k2Yl+I4+A8yp+SLRei8zkSbW3BMgJ0TjAhcCBIf6xfQgOXM2l37Q == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrudekvddgleejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsegrtd erreerredtnecuhfhrohhmpedftehlvgigvgihucfovghlnhhikhhovhdfuceorghlvgig vgihrdhmvghlnhhikhhovhesihhsohguvgdrtghomheqnecuggftrfgrthhtvghrnheptd ejhfegfedtgfehfeehtefhfeffledufeekueehhfejgfejtdelveetueeufeelnecuffho mhgrihhnpehivghtfhdrohhrghenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmh epmhgrihhlfhhrohhmpegrlhgvgigvhidrmhgvlhhnihhkohhvsehishhouggvrdgtohhm X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 0095C6F60060; Fri, 11 Dec 2020 11:59:09 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-622-g4a97c0b-fm-20201115.001-g4a97c0b3 Mime-Version: 1.0 Message-Id: <65714d6f-1074-4cb6-a939-6b8ef07e907a@www.fastmail.com> In-Reply-To: References: <160745190172.15620.17081247178872475062@ietfa.amsl.com> Date: Fri, 11 Dec 2020 16:57:46 +0000 From: "Alexey Melnikov" To: "Kurt Andersen" Cc: "dmarc@ietf.org" , "Murray S. Kucherawy" , dmarc-chairs@ietf.org Content-Type: multipart/alternative; boundary=71913aa662224e1486519962a399762e Archived-At: Subject: Re: [dmarc-ietf] dmarc - New Meeting Session Request for IETF 110 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 11 Dec 2020 16:59:39 -0000 --71913aa662224e1486519962a399762e Content-Type: text/plain Hi Kurt, Murray will correct me if I am wrong, but I have several comments: On Fri, Dec 11, 2020, at 12:37 AM, Kurt Andersen (b) wrote: > I'm wondering why we should wait for IETF110 rather than having an interim meeting sooner. Interim meetings are also likely to garner greater participation since they do not include participation fee. If there are topics worthy of F2F discussion, why wait? If there are not, then why charge people to join a pointless meeting? 1). All online IETFs this year had "free attendence" option. If people can afford to pay to attend, they should, as this supports RFC publication cost, cost of online meetings, etc. But people can attend for free if needs be. As far as I know this is going to be the case for IETF 110. 2). Chairs are considering interims and we will schedule them if/when needed. 3). Chairs will discuss around February 1st whether we think we can have a productive meeting at IETF 110. We can cancel if there are no reasons to have online meeting during IETF 110 week. Best Regards, Alexey > > --Kurt > > On Tue, Dec 8, 2020 at 10:25 AM IETF Meeting Session Request Tool wrote: >> >> >> A new meeting session request has just been submitted by Alexey Melnikov, a Chair of the dmarc working group. >> >> >> --------------------------------------------------------- >> Working Group Name: Domain-based Message Authentication, Reporting & Conformance >> Area Name: Applications and Real-Time Area >> Session Requester: Alexey Melnikov >> >> >> Number of Sessions: 1 >> Length of Session(s): 1 Hour >> Number of Attendees: 76 >> Conflicts to Avoid: >> Chair Conflict: dnsop dprive cfrg kitten emailcore >> Technology Overlap: saag uta extra jmap cbor >> >> >> >> >> >> >> People who must be present: >> Alexey Melnikov >> Murray Kucherawy >> Tim Wicinski >> Seth Blank >> >> Resources Requested: >> >> Special Requests: >> >> --------------------------------------------------------- >> >> >> _______________________________________________ >> dmarc mailing list >> dmarc@ietf.org >> https://www.ietf.org/mailman/listinfo/dmarc --71913aa662224e1486519962a399762e Content-Type: text/html Content-Transfer-Encoding: quoted-printable
Hi Kurt,

Murray will correct me if I am wrong, but I have = several comments:

On Fri, Dec 11, 2020, at 12:3= 7 AM, Kurt Andersen (b) wrote:
I'm wondering why we should wait fo= r IETF110 rather than having an interim meeting sooner. Interim meetings= are also likely to garner greater participation since they do not inclu= de participation fee. If there are topics worthy of F2F discussion, why = wait? If there are not, then why charge people to join a pointless meeti= ng?
1). All online IETFs this year had = "free attendence" option. If people can afford to pay to attend, they sh= ould, as this supports RFC publication cost, cost of online meetings, et= c. But people can attend for free if needs be.
As far as I= know this is going to be the case for IETF 110.

2). Chairs are considering interims and we will schedule them if/= when needed. 

3). Chairs will discuss arou= nd February 1st whether we think we can have a productive meeting at IET= F 110. We can cancel if there are no reasons to have online meeting duri= ng IETF 110 week.

Best Regards,
Alexey



--Kurt

On Tue, Dec 8, 2020 at 10:25 AM IETF Meeting Sessio= n Request Tool <session-r= equest@ietf.org> wrote:


A new meeting session request has just been submitted by Alexey Melni= kov, a Chair of the dmarc working group.

=
--------------------------------------------------------= -
Working Group Name: Domain-based Message Authentication= , Reporting &amp; Conformance
Area Name: Applications= and Real-Time Area
Session Requester: Alexey Melnikov


Number of Sessions: 1
Length of Session(s):  1 Hour
Number of At= tendees: 76
Conflicts to Avoid:
 Cha= ir Conflict: dnsop dprive cfrg kitten emailcore
 Tec= hnology Overlap: saag uta extra jmap cbor

=




People who must be present:
  Alexey Melnik= ov
  Murray Kucherawy
  Tim Wici= nski
  Seth Blank

Res= ources Requested:

Special Requests:

----------------------------------------------= -----------


_____________= __________________________________
dmarc mailing list
=
--71913aa662224e1486519962a399762e-- From nobody Fri Dec 11 09:07: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 B25B43A0CFE for ; Fri, 11 Dec 2020 09:07:31 -0800 (PST) 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 08bs9rprz-m8 for ; Fri, 11 Dec 2020 09:07:30 -0800 (PST) Received: from mail-pl1-x636.google.com (mail-pl1-x636.google.com [IPv6:2607:f8b0:4864:20::636]) (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 5C2843A0C57 for ; Fri, 11 Dec 2020 09:07:30 -0800 (PST) Received: by mail-pl1-x636.google.com with SMTP id t6so4900554plq.1 for ; Fri, 11 Dec 2020 09:07:30 -0800 (PST) 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=4/bSXJ1IDmLW8Gvkx6vk+BFeNHymf9RQfZaoRpEMyCA=; b=aXolg4Suq49fywDiweZ8NTk6rOMIGkKf7+ELKJb419Mxvm+bPhIRF2b7qlYljavodt sly8FjgkxKGgzThFLqvNohAvVw6L6nR1c1iYh9uQ41QGNpGrrgEBNiJtROcQ4WCYLqw2 hEqC9KpzUTSB3MH1mQYO2k34CqHmiyEQsZ8DzmdSOCxWmXaYLZ2xatNWTfA+xN8lLupq jaY17LEd94Id5uY24v/8emF/OlQ80x2v3AijABClmK1CODrws7b/Fc6h2H1y2k8QPvfx 7XsMRU6UjDAtvqapEXpXcFpyIaOQOcOOIEYrtnjGnIP6W/iwc69ZKQgN6M2OmdPzJR7+ uY1g== 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=4/bSXJ1IDmLW8Gvkx6vk+BFeNHymf9RQfZaoRpEMyCA=; b=GZ7qiHfzbtterkDBG9uGOMLNxA1fTsNNOqEypsa4LnzpY4HIm5CETkBihRXv82IQdA QXgpl96XPs9V4nw0qaOh7yw7qyFW0OUXD5PlJG/n3GA3IUTn1u/OhOIzITAewoIokLIf NRLSz4ZPVLr3CcOLDhEWYYvNK26txhvDEzLB4EwHPX3znKgRH9AWJOQDlNAOtCUMMXTr Jxo/rVVNT7sOqMxs8bZPi3tti7wRFWQYiOpuN5BmlN5PDoyeTkrIxeRZ0SepFDAprprA vrFh3TpMgbON6SoYJSpHwunTni33ec5fls3M5PmUC7osk8bmZwyUr3R/lzxM3Hgw8IZl P6iQ== X-Gm-Message-State: AOAM533oVSGeU9T5w46+12oyk+FKe6MfHs5aIPPMcFYI0qvOd2q6aC1Y eNYB6pGys9eKbIU1XyusGSM1aNVjgPY= X-Google-Smtp-Source: ABdhPJyKmbDuPj59zZXI0qQdHyMmk5Sjp3AA+QmEKx4/2FUdebtAnro8HHujrmTtwotTPj8eQDlzig== X-Received: by 2002:a17:90a:315:: with SMTP id 21mr12168935pje.25.1607706448981; Fri, 11 Dec 2020 09:07:28 -0800 (PST) Received: from [192.168.0.109] (c-24-130-62-181.hsd1.ca.comcast.net. [24.130.62.181]) by smtp.gmail.com with ESMTPSA id u15sm11210088pju.7.2020.12.11.09.07.27 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 11 Dec 2020 09:07:28 -0800 (PST) To: IETF DMARC WG References: <923de33f-3707-facf-389e-371f6ee64008@gmail.com> <16B0B820-7080-4937-8642-3A6B84B441AA@gmail.com> <1f5b3e62-e6f4-0bc2-221e-362667536727@gmail.com> <8e0ff141-2842-606c-91e9-e588edab7ef1@gmail.com> From: Dave Crocker Message-ID: <80e6ebf8-b66f-a1f5-7ddd-1aed55c3be0d@gmail.com> Date: Fri, 11 Dec 2020 09:07:26 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------A17E3F900AC6755F39DAF059" Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] p=quarantine X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 11 Dec 2020 17:07:32 -0000 This is a multi-part message in MIME format. --------------A17E3F900AC6755F39DAF059 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 12/11/2020 8:32 AM, Kurt Andersen (b) wrote: > > Perhaps: >      none: not certain at all >      quarantine: I believe I've got control of all my sending, but am > not 100% positive >      reject: I have control of all my sending; if it doesn't pass > DMARC, > it's use of the domain is bogus. > > > But the problem case in our off-topic rabbit trail meanderings is that > people who "have control of all their sending" still don't necessarily > send mail of consistent seriousness nor do they have any control of > the paths by which that mail takes to get to the ultimate recipient. > There is a conflation of "control of emission" with "control of path". A specification providing a choice of labels/settings needs to have a shared understanding of what those labels mean. It seems pretty clear that DMARC's p= hasn't had that, to date. There is no consistency to the criteria used to set the label and, I suspect, little consistency to how a receiver's filtering engine uses it. We need to settle on text that resonates with a consistent interpretation, by both domain owners and email receivers. I've offered an approach that might permit reaching that community -- not just IETF -- rough consensus. At this point we need to get suggested revisions for improvement. For now, I don't have better text to suggest. d/ -- Dave Crocker dcrocker@gmail.com 408.329.0791 Volunteer, Silicon Valley Chapter American Red Cross dave.crocker2@redcross.org --------------A17E3F900AC6755F39DAF059 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 12/11/2020 8:32 AM, Kurt Andersen (b) wrote:
Perhaps:
     none: not certain at all
     quarantine: I believe I've got control of all my sending, but am
not 100% positive
     reject: I have control of all my sending; if it doesn't pass DMARC,
it's use of the domain is bogus.

But the problem case in our off-topic rabbit trail meanderings is that people who "have control of all their sending" still don't necessarily send mail of consistent seriousness nor do they have any control of the paths by which that mail takes to get to the ultimate recipient. There is a conflation of "control of emission" with "control of path".


A specification providing a choice of labels/settings needs to have a shared understanding of what those labels mean. 

It seems pretty clear that DMARC's p= hasn't had that, to date.  There is no consistency to the criteria used to set the label and, I suspect, little consistency to how a receiver's filtering engine uses it.

We need to settle on text that resonates with a consistent interpretation, by both domain owners and email receivers.

I've offered an approach that might permit reaching that community -- not just IETF -- rough consensus. 

At this point we need to get suggested revisions for improvement. For now, I don't have better text to suggest.

d/

-- 
Dave Crocker
dcrocker@gmail.com
408.329.0791

Volunteer, Silicon Valley Chapter
American Red Cross
dave.crocker2@redcross.org
--------------A17E3F900AC6755F39DAF059-- From nobody Fri Dec 11 09:21: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 124693A0D32 for ; Fri, 11 Dec 2020 09:21:22 -0800 (PST) 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 hVvZnBYohVVF for ; Fri, 11 Dec 2020 09:21:20 -0800 (PST) Received: from mail.wordtothewise.com (mail.wordtothewise.com [104.225.223.158]) by ietfa.amsl.com (Postfix) with ESMTP id 704B93A0D21 for ; Fri, 11 Dec 2020 09:21:20 -0800 (PST) Received: from [192.168.0.227] (unknown [37.228.231.27]) by mail.wordtothewise.com (Postfix) with ESMTPSA id 338829F149 for ; Fri, 11 Dec 2020 09:21:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=wordtothewise.com; s=aardvark; t=1607707279; bh=GTEqo/ptLSb2bNyHI0bu2bSFdhDxCwz1ZYGcU67mBS0=; h=From:Subject:Date:References:To:In-Reply-To:From; b=HoVfUu+JgRqZWV6TDJS4oXa9nyt++p3C2dvR/Km+yi2dMU5fm2N7rPu/uqC7Bltg7 sCmLk3jLh6gkGHjg3vENBnKufh+irRssxasMaVMw5F9RpZ+cCZgtzS2TE9e89bWGVg kAOCmOyoZVzYZHwVOV27PmjGnp0rAG0puzrPz498= From: Laura Atkins Content-Type: multipart/alternative; boundary="Apple-Mail=_B6CBEF0D-C4E3-4F1A-B8E4-74A50C156105" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Date: Fri, 11 Dec 2020 17:21:17 +0000 References: <923de33f-3707-facf-389e-371f6ee64008@gmail.com> <16B0B820-7080-4937-8642-3A6B84B441AA@gmail.com> <1f5b3e62-e6f4-0bc2-221e-362667536727@gmail.com> <8e0ff141-2842-606c-91e9-e588edab7ef1@gmail.com> <80e6ebf8-b66f-a1f5-7ddd-1aed55c3be0d@gmail.com> To: IETF DMARC WG In-Reply-To: <80e6ebf8-b66f-a1f5-7ddd-1aed55c3be0d@gmail.com> Message-Id: <1AC986FF-507B-4917-9C6D-D84E9337FC7A@wordtothewise.com> X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [dmarc-ietf] p=quarantine X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 11 Dec 2020 17:21:22 -0000 --Apple-Mail=_B6CBEF0D-C4E3-4F1A-B8E4-74A50C156105 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 11 Dec 2020, at 17:07, Dave Crocker wrote: >=20 > On 12/11/2020 8:32 AM, Kurt Andersen (b) wrote: >> Perhaps: >> none: not certain at all >> quarantine: I believe I've got control of all my sending, but am=20= >> not 100% positive >> reject: I have control of all my sending; if it doesn't pass = DMARC,=20 >> it's use of the domain is bogus. >>=20 >> But the problem case in our off-topic rabbit trail meanderings is = that people who "have control of all their sending" still don't = necessarily send mail of consistent seriousness nor do they have any = control of the paths by which that mail takes to get to the ultimate = recipient. There is a conflation of "control of emission" with "control = of path". >=20 > A specification providing a choice of labels/settings needs to have a = shared understanding of what those labels mean. =20 >=20 > It seems pretty clear that DMARC's p=3D hasn't had that, to date. = There is no consistency to the criteria used to set the label and, I = suspect, little consistency to how a receiver's filtering engine uses = it. >=20 > We need to settle on text that resonates with a consistent = interpretation, by both domain owners and email receivers. >=20 > I've offered an approach that might permit reaching that community -- = not just IETF -- rough consensus. =20 >=20 > At this point we need to get suggested revisions for improvement. For = now, I don't have better text to suggest. >=20 There=E2=80=99s probably better phrasing than =E2=80=98DMARC = compliant=E2=80=99 here, but here=E2=80=99s my stab at describing the = processes. note, this is very close to the language I use with clients. p=3Dnone: mail sent by authorized users of this domain may or may not be = aligned in a DMARC compliant way. p=3Dquarantine: mail sent by authorized users of this domain should be = aligned in a DMARC compliant way. Mail that is unaligned may or may not = be legitimate messages from this organization. p=3Dreject: all mail sent from this domain should be aligned in a DMARC = compliant way. Mail that is unaligned is not authorized by the domain = owner and may be discarded or rejected by the recipient.=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=_B6CBEF0D-C4E3-4F1A-B8E4-74A50C156105 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On 11 Dec 2020, at 17:07, Dave Crocker <dcrocker@gmail.com> = wrote:

=20 =20
On 12/11/2020 8:32 AM, Kurt Andersen (b) wrote:
Perhaps:
     none: not certain at all
     quarantine: I believe I've got control = of all my sending, but am
not 100% positive
     reject: I have control of all my = sending; if it doesn't pass DMARC,
it's use of the domain is bogus.

But the problem case in our off-topic rabbit trail meanderings is that people who "have control of all their sending" still don't necessarily send mail of consistent seriousness nor do they have any control of the paths by which that mail takes to get to the ultimate recipient. There is a conflation of "control of emission" with "control of = path".


A specification providing a choice of = labels/settings needs to have a shared understanding of what those labels mean. 

It seems pretty clear that DMARC's p=3D hasn't had = that, to date.  There is no consistency to the criteria used to set the label and, I suspect, little consistency to how a receiver's filtering engine uses it.

We need to settle on text that resonates with a = consistent interpretation, by both domain owners and email receivers.

I've offered an approach that might permit reaching that community -- not just IETF -- rough consensus. 
=

At this point we need to get suggested revisions = for improvement. For now, I don't have better text to = suggest.


There=E2=80= =99s probably better phrasing than =E2=80=98DMARC compliant=E2=80=99 = here, but here=E2=80=99s my stab at describing the processes. note, this = is very close to the language I use with clients.

p=3Dnone: mail sent by authorized users of this = domain may or may not be aligned in a DMARC compliant way.

p=3Dquarantine: mail sent by authorized users of = this domain should be aligned in a DMARC compliant way. Mail that is = unaligned may or may not be legitimate messages from this = organization.

p=3Dreject: all mail = sent from this domain should be aligned in a DMARC compliant way. Mail = that is unaligned is not authorized by the domain owner and may be = discarded or rejected by the recipient. 

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=_B6CBEF0D-C4E3-4F1A-B8E4-74A50C156105-- From nobody Fri Dec 11 09:24: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 664733A0D38 for ; Fri, 11 Dec 2020 09:24:26 -0800 (PST) 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 P9N8jUBprYz8 for ; Fri, 11 Dec 2020 09:24:24 -0800 (PST) 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 7E2CE3A0D21 for ; Fri, 11 Dec 2020 09:24:24 -0800 (PST) Received: from NAM12-DM6-obe.outbound.protection.outlook.com (mail-dm6nam12lp2170.outbound.protection.outlook.com [104.47.59.170]) by smtpauth3.wiscmail.wisc.edu (Oracle Communications Messaging Server 8.0.2.4.20190812 64bit (built Aug 12 2019)) with ESMTPS id <0QL600AOYR0L0F70@smtpauth3.wiscmail.wisc.edu> for dmarc@ietf.org; Fri, 11 Dec 2020 11:24:22 -0600 (CST) 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.12.11.172117, AntiVirus-Engine: 5.79.0, AntiVirus-Data: 2020.11.19.5790001, SenderIP=[104.47.59.170] ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=mzwsLIES97wplXMe53zZdnYV8Fuw1+uG+ZzeOTt7DNuRaYjkSgefvM7Gt7tVfO1fST/uTHMGuVfhoR0i4xuSxqGgW2QA/1qkTyeEe4E+ySpxsrmKuPE4dTxjQrg1E7wajJBMTi7VWszr71MbgdK0vZcEG/veteqyQfz02DxUP/zv0ON0u0eArAkkGGPnQInqJbBhMZJ2ZlVufEwEprOQ0GPOQjFCLpRAJQMUl4uXUNKhCJ0oh1TSrzTUIJjTcqIp6ZlJF/8V5uiHQNZAseNgzOpB2jCo291RCrJM/+UKjzGz22ujKd5cEaOE80elm5tFR6/pdL4CPt3nJSBKUkSwTQ== 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=C5/5l0yEDAtc2R6B/Hq2nnx5CPmYT3WhPvmvdkiElRs=; b=WTWw6NpDs6wtzEX+ZtJm5L/LWc4dJMO5Y84Wt7i/6jsdaojmeaDcuM4FiABMGcPEZjjOyho2OQYBIzIymmtznqYO4DCXeELbEuqDL0K04gajb7qjHHs8n876S/XgKKAS55gdR+e3Vc1rzJrDdK7v7oWunhr8btJaMVCyLu+8C5bM7W+hsIpWNgew17iy50hLE6xe9vVnlW7MZNLoRfPcruRVQuGhvAnseagNOHI0xw+/h/mL0Wir18JKTCRAd/wxUZTYGsHPfPx/0Fo1UWnU2GO+6DaiG51w42sjoEGqI1QInaWkdwT+BjdwkRoBjHWyHj2kbymcmo83by0DuE3zjg== 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=C5/5l0yEDAtc2R6B/Hq2nnx5CPmYT3WhPvmvdkiElRs=; b=fCOb7ZhSe8oqr41gtF8MO/YbpUTHVevw/hxE2/73u4PW+uVotzZsyjtoEhBtXY3FEaSJdxsXYgcI6xzrR2MAfJNU+HpnLrNUUOLZ3b39nVZNTN7lbkI8txSqpYcvHXb321O72+SKyVQhSlj3ZSNnpB/TDclDzfo7HUxQlPvKdzk= Received: from CO6PR06MB7059.namprd06.prod.outlook.com (2603:10b6:5:342::18) by CO6PR06MB7298.namprd06.prod.outlook.com (2603:10b6:5:353::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3632.17; Fri, 11 Dec 2020 17:24:19 +0000 Received: from CO6PR06MB7059.namprd06.prod.outlook.com ([fe80::852d:bd8b:f632:f4ca]) by CO6PR06MB7059.namprd06.prod.outlook.com ([fe80::852d:bd8b:f632:f4ca%5]) with mapi id 15.20.3654.012; Fri, 11 Dec 2020 17:24:19 +0000 To: Alessandro Vesely , dmarc@ietf.org References: <609e1c9b-cc4d-d7d1-0fa8-79f515c1eee4@tana.it> <20201209185246.1D40C29474C4@ary.qy> <747eae71-24e7-fd05-2123-2c22ae4588e8@tana.it> From: Jesse Thompson Message-id: <20575bf1-3813-4b3c-e59c-54e38b0da670@wisc.edu> Date: Fri, 11 Dec 2020 11:24:16 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 In-reply-to: <747eae71-24e7-fd05-2123-2c22ae4588e8@tana.it> Content-type: text/plain; charset=utf-8 Content-language: en-US Content-transfer-encoding: 7bit X-Originating-IP: [146.151.213.183] X-ClientProxiedBy: CH2PR02CA0009.namprd02.prod.outlook.com (2603:10b6:610:4e::19) To CO6PR06MB7059.namprd06.prod.outlook.com (2603:10b6:5:342::18) MIME-version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [146.151.213.183] (146.151.213.183) by CH2PR02CA0009.namprd02.prod.outlook.com (2603:10b6:610:4e::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3654.12 via Frontend Transport; Fri, 11 Dec 2020 17:24:18 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: 8c5b8729-aef5-4928-e1ef-08d89df997e6 X-MS-TrafficTypeDiagnostic: CO6PR06MB7298: 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: v1WHUBEfVRQrOp/IS2AdV7Kl9E45k99B09BuTyR1Sg7rWCsWqSTyHRCZ3G8/RZBkZi/6H0x2LLzWuDHLLVh7iB49Tfnseb//RcD8COwACeUemSQEgKt5Gx3nvGtHFWsWkKA0SvVO1jwhE5caXzMuV6+fR2U6vB22l0vMbVwdoKUvalHhCegZODSTn6Eq3HPpMKMlMQwPDXgZnCKO63QeYyPQNkh9uF9CfA7YAxBnoS3i380ZK+N74rd451UOSHfcfH9yRERkZFw13gy1mfAHPdcrNhX2xCqB3BYy9TtGinxyfGR3vZpyFudrtYeMsDKpzwmu60gzYEVUjhYXIeOfow7KKAoTfhzllRq91d04J1PHTBibFns/7p2Rmwnh7AvlVrAxh+bwZraU6bWB/A0f4FVONeoo5yXbHzAG2S/MMTgHq6PQPyLGDXeogcybYK3k X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CO6PR06MB7059.namprd06.prod.outlook.com; PTR:; CAT:NONE; SFS:(136003)(346002)(376002)(366004)(6486002)(2906002)(31686004)(5660300002)(6706004)(31696002)(16526019)(53546011)(86362001)(186003)(66476007)(8676002)(956004)(44832011)(786003)(75432002)(2616005)(83380400001)(36756003)(508600001)(66946007)(26005)(16576012)(8936002)(66556008)(3940600001)(43740500002)(45980500001); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: =?utf-8?B?M2gxaVhZV29WS1NWekVMTDYzL3dDY0gvSWlhRGFmUUZJeHRGcG5aQ2NZeHlC?= =?utf-8?B?UGRCWWdUb2t4ZmZDQ3ROR0Z2N29WUldDTVRnYTBpaDF5cm9IWCttUUtodWtt?= =?utf-8?B?bkFvSVhsSTFSbFRZVUVFUzByWkNyOGFsNmZXWGJqYW4yWFM0cHJlLzlZa05o?= =?utf-8?B?bTVLc3FQYlZNcHVaNUZUMndiSXhka1hvSTVYa25CS2VMVThYelovekJCeG1B?= =?utf-8?B?YVhKWldwV0t1MHpJbGdzRHBXMTQyTURrcTF1VFVuaElYVVhiK08wczJlQWJR?= =?utf-8?B?YjBhU3h2NnNnU2tDN3ZUVDU4bHdQZjE5TUttK3BTMG1yRjNuSW5OT25vTkM2?= =?utf-8?B?R0d0Wk1icUltK3AvTU96YXg2cG1DdUk0dzNFY0h3c2QxSGpid0UxaFB5OUZx?= =?utf-8?B?K2xDS2Y3VDM5VXJFLzBNTHlrODZaTlo2MWcwaEZsZmNvNHhtUFhGV2I3THRm?= =?utf-8?B?M2tIVTcyZEhXcTQxTE16SnJsY3kxMXpsL043bS9PUTdaWW5rYXFMNlVnb3Z2?= =?utf-8?B?RUE2My8zcGExS0hHU1hxdEZ5NVJyQkNRSTc4cjU3TGxYWVUvdzY4eG1xZVJZ?= =?utf-8?B?T2pBYWN6R3ozV2xqS3NqN0lBOHhWNXJmOUxqcnhKUjl0SkxzaHd5bkhYNVBT?= =?utf-8?B?QXNMSlFaWjBrYlJkeWU4eUd3Ti9MRzV3NkdDbXFNN2dZZWc3alVjMHpwN2c3?= =?utf-8?B?aFpqTEFNaExCZi9kU2RrYjBVMDlXV3RrZWtqNmNveFcwSWFBb0tRamtldGJ4?= =?utf-8?B?WlZyVDMrMFY5aFBsUjNXdmtibHd0OGExdVJSYkV6U050Sjl2anhHZ09qSk9k?= =?utf-8?B?R0Fnc1Vhak93T2FUTzNxWjArWDl0RlNBazVVWlJTenJ3eURPZWY5S0dpUHho?= =?utf-8?B?bWgyVTI2UDh5ZXVDNUYxRWs3dEc5SjlucnphSnlRancxSk4vU0pNVFozWUhY?= =?utf-8?B?TmhFMU9idDdvMDcyY2lsWHRYY0xqMmZDWSsyT21rUS83eENidzZnUU10aHJ5?= =?utf-8?B?ZWt2dDArUVRURXJsWWd3cHNRY21uSE9ETlFXRjRxSnhNUzJVUUNEbjhpaWF1?= =?utf-8?B?cFJ0Zk45NHZ4SE43OEY0VzlLS29BUmxnTndJUWM1V0lqZW1DbEZMYmk2T1ow?= =?utf-8?B?Q3dVK0t0WkxFOUQ2T0kzWGV2YkhMSjBLVHF3Y2pBKzdMVzErQzQ0V0VNRFNT?= =?utf-8?B?bjMxajl4a2pWZlZLeGdsOFQyMjdRNVdkamg0T01GSFFiTW81cHl1UVNESUtB?= =?utf-8?B?YllzdW94NlN4ZmNpcEtqRTVvUzBzQU55cXhNdGdWUFhWdTZXcGlibmlsQ0xN?= =?utf-8?Q?FSLFqzuzYPK4F3jcqgTMPNFgCD+hQMUjvC?= X-OriginatorOrg: wisc.edu X-MS-Exchange-CrossTenant-AuthSource: CO6PR06MB7059.namprd06.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Dec 2020 17:24:19.2877 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 2ca68321-0eda-4908-88b2-424a8cb4b0f9 X-MS-Exchange-CrossTenant-Network-Message-Id: 8c5b8729-aef5-4928-e1ef-08d89df997e6 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: ouBJCM8voNrj7leMYF/SamF1LCbd87YoKITgg5c60mnCRwKiOTIOEjhv3syulcyvtiL0b9xtknxyMooX2bweLQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO6PR06MB7298 Archived-At: Subject: Re: [dmarc-ietf] Ticket #61 - Define and add a simplified (redacted) failure report X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 11 Dec 2020 17:24:26 -0000 On 12/11/20 7:48 AM, Alessandro Vesely wrote: > On Thu 10/Dec/2020 17:59:54 +0100 Jesse Thompson wrote: >> On 12/9/20 10:28 PM, seth wrote: >>> As an individual, I feel extremely strongly that failure reports should go away in their entirety. Although Jesse Thompson has outlined a use case that really has no other good solution, and is equally true in other large complicated organizations. >> >> To be clear, I'm not advocating for this From/To use case, but I know of universities who would. There's at least one who cleverly flattened their SPF record to include every known sender specifically because they had no mission to change the way their institution distributively sends email. That is the type of organization who *may* want From/To data, assuming they want to do more validation before adding yet another IP to their SPF. It's a stretch in my mind. > > > I'm not clear whether you're talking about sending or receiving reports. Received: chains are key for evaluating addresses to add to SPF records. I don't think it makes sense to specify their omission from Only the last hop from the receiver's viewpoint is really needed for a domain owner to assess gaps in SPF. That's already addressed with aggregate reports. What's missing is the additional context that the failure reports are intended to provide, to help domain owners determine if the IP address which sent the message was legitimate. Of course, received chains are helpful for troubleshooting. There's no "right" answer regarding the balance of useful information vs privacy, so I'm suggesting that we put things like this on a spectrum of usefulness/privacy-concerning. > My guess at why an organization may want to send only From/To rather than a possibly redacted text/rfc822-headers are as follows: > > * It is too hard for them to asses the risk of including unknown header fields, yet they must do it before enabling ruf, > > * the software they use doesn't have an option to redact PII, or (unlikely) > > * they try to save bandwidth and disk space by reducing that ghastly pile of freaky fields that infest message headers these days. If sending only a limited amount of information is considered an acceptable alternative to full/unredacted information, it might help encourage these organizations to send failure reports, perhaps? >> I would only strongly advocate for seeing the unredacted From header, since my primary concern was with identifying a little bit more information about who was using the domain and why (i.e. who is using random ESP). > > > Agreed. > > >> The stated purpose of Failure Reports is "for quickly notifying the Domain Owners when there is an authentication failure ... also provide more information about the failed message than is available in an aggregate report". Since the focus of DMARC is to authorize the use of the domain used in the From header, then the logical next incremental levels of "more information" should be: >> >> 1) From header domain (already known) >> 2) local part of From address >> 3) Friendly From >> 4) Subject >> 5) other parts of the message containing identifiable information >> >> 1->5 decreases in usefulness/relevancy to DMARC >> 1->5 increases in unnecessary information disclosure > > > The mail filter I do sends aggregate reports but not failure reports. Should I add it? I'm thinking I could frame it like so: > > * Have a global flag to enable or disable ruf's, which can be overridden on a per-domain basis. Default to disabled. > > * The flag can specify three confidentiality levels: > - full message > - header only > - header only + redact. > > * Redacting the header would work as follows: > 1. Collect recipients addresses in To:, Cc:, and envelope, > 2. compute the rfc6590-redacted version of each address, > 3. for all fields, replace any occurrence with the redacted version. > > * Reports are left in a user-configured directory, assuming that a user supplied script deals with them. > > Does that make sense? > > Should dmarc-failure-reporting include text with practical suggestions along those lines? Does this redaction logic apply to the From header too? If so, I would recommend adding a fourth confidentiality flag for reporters who want to redact recipient information but leave the From header unredacted to better aid the domain owner in tracking down the sender. Jesse From nobody Fri Dec 11 09:37:28 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4A7A3A0D3C for ; Fri, 11 Dec 2020 09:37:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.851 X-Spam-Level: X-Spam-Status: No, score=-1.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iecc.com header.b=qmsKKQV7; dkim=pass (2048-bit key) header.d=taugh.com header.b=JIETUuJy Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 34TKW_66fHbA for ; Fri, 11 Dec 2020 09:37:25 -0800 (PST) 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 96AAE3A0D39 for ; Fri, 11 Dec 2020 09:37:24 -0800 (PST) Received: (qmail 30557 invoked from network); 11 Dec 2020 17:37:23 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=775b.5fd3ae53.k2012; bh=nOTnKy/NyOykZHDPOJ1z4XUeMRFnBRhmh0jENDcStow=; b=qmsKKQV7zw+8zTXri4QoJGpNN/FJq0Em1w8yZ2tBi+DzKOCFgaUtsdKrON06XMRSLcqH6lH6b+GnEB4YJKcD0jDqOecviHmVHC3Up3AiOsPA+yI0AnkzPFMiEXRgyotfzjWaBbVrJQ+JdhOFM9Ad5eH5ZkLqw80ISemRD/qIgGy/nlx0j41MXHdCTZOCB2A9PSR5BbVzqqTpwazId2CJMT4/hd3d7xC08xv7qaYgrj8yRZ0ZFUl4i67b2ae1NVAP+dUvPlEU3qvExO1xZCYE96nt2fSDUzJyoNSUZYO5WuKOKw0g34PAC3xMcbgwvChCbSwOpjI+9IK8fZGy0chBCQ== DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=775b.5fd3ae53.k2012; bh=nOTnKy/NyOykZHDPOJ1z4XUeMRFnBRhmh0jENDcStow=; b=JIETUuJyre4fAVjQDk+BbdSXsIg6+8iypkzFAxYc2wQmMPrCH7Cu29wHcJym/QjfZMO9g2USuErfkeT9Xoe95CvawRAEda1I3XDjypOzK2UcE4gD15AJpUrvXEPjT656+CgISNez1pRvQPhUBJJaykSilsbUvUHw1u2H7at9jZYIB6nCgVEraQs5TmvtDGe/209HVQ13sptPEqAoSeofKJkYlfDN+zovqDA7Ess2c8pOLWwJ0uT9D0V3k/7SxaoCtJ0oMKxMlz/aIK8XaChUv+uGQwzHE2wHv1BqZlyJrmwFgxA4h4KNvi5UDLomZueQqFd7cvpy7rC+319HBOo+QA== 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; 11 Dec 2020 17:37:22 -0000 Received: by ary.qy (Postfix, from userid 501) id 6B4DF29782C7; Fri, 11 Dec 2020 12:37:22 -0500 (EST) Date: 11 Dec 2020 12:37:22 -0500 Message-Id: <20201211173722.6B4DF29782C7@ary.qy> From: "John Levine" To: dmarc@ietf.org Cc: laura@wordtothewise.com In-Reply-To: <1AC986FF-507B-4917-9C6D-D84E9337FC7A@wordtothewise.com> Organization: Taughannock Networks X-Headerized: yes Cleverness: minimal Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] p=quarantine X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 11 Dec 2020 17:37:27 -0000 In article <1AC986FF-507B-4917-9C6D-D84E9337FC7A@wordtothewise.com> you write: >p=none: mail sent by authorized users of this domain may or may not be aligned in a DMARC compliant way. > >p=quarantine: mail sent by authorized users of this domain should be aligned in a DMARC compliant >way. Mail that is unaligned may or may not be legitimate messages from this organization. So far so good. >p=reject: all mail sent from this domain should be aligned in a DMARC compliant way. Mail that is >unaligned is not authorized by the domain owner and may be discarded or rejected by the recipient. Naah. p=reject: all mail sent from this domain should be aligned in a DMARC compliant way. We believe that unaligned mail is from unauthorized senders so we ask receivers to reject it, even though that might mean some of our authorized senders' mail is rejected too. R's, John PS: I had more or less this same discussion leading to ADSP discardable. From nobody Fri Dec 11 09:49: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 6FEC23A0D40; Fri, 11 Dec 2020 09:49:46 -0800 (PST) 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 br44dBHmuLiQ; Fri, 11 Dec 2020 09:49:45 -0800 (PST) Received: from mail-ua1-x929.google.com (mail-ua1-x929.google.com [IPv6:2607:f8b0:4864:20::929]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D06453A0D39; Fri, 11 Dec 2020 09:49:44 -0800 (PST) Received: by mail-ua1-x929.google.com with SMTP id f16so3103876uav.12; Fri, 11 Dec 2020 09:49:44 -0800 (PST) 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=LEpLtxDIbHvaOawc93uU4ma4Yd0JThCsNoMS9TcgZrg=; b=iCwmvHGWbnNJ3FaP5Qx5aYZxGI4p8WFK2nimFTVpbO8QGinJn4Aeki4gDPTuw1Mnhx kktZ2YyP/G65zCJCzmSVWvtco/KHr/kFpqAYhE11QxUtVg5QJwrm2CGTztnKy/SsjD7G luuTjexYPOqqos4B2NJQZq//dDYtSk57ygUOPT5LpwCEj3u3+as67kUYJgxTkjdI6zyI DLS8NINnFk8O44SEvfj5tq8SjYcuS8Mee4hDZlHL1KcohzxAIwje+dnv7vXrC4zM0V07 TY10NEaBrvvJSDYvBNZeGnsIzVedQvFqNzAd6bc/wIv5A7D5ReCeFeBzt6nDcWXDJz1v ofYw== 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=LEpLtxDIbHvaOawc93uU4ma4Yd0JThCsNoMS9TcgZrg=; b=P8BIoloUECSaXoz7nzUTA3/xENQadj2h/VXwvgX0y4w1A64XT+3y5lO2qKJOwIQwqY mFc9Tod8HhhorvUp3IqczyovdwaEnezN9FvmIR6WsZ5KUTM8G72uXCnVs9YqMZe637rC DVR4CZflak2qxSE0F9IY4KcVfsFOCLcHHy6xfHKX9TJYubKpf05/6J0qP10N/PzMV1ES NTQYQ6C8IAcq3kMEUp3y+SBPL8esW+F+gpUwtZVLdXPilIfQAxBvINzB/VPvRwI8Owi+ k8W3ydiDb4mAYW/BZsGDnrnPvOaZpx9J3HdYnwWHCmaC7FBzRqpcrUnszJ4CxiFr+xxK TZ6Q== X-Gm-Message-State: AOAM530oCIEguFkZ+0paZ4owtRP2pMK7gVEmyRAID6EfN4RJg5UTiZwy 8DCTmqtayr9iMzxyP9GBiWSfm5PRIzVWtKuhSMU= X-Google-Smtp-Source: ABdhPJzvr5SqHIHUVrW9XA4mruv+PfRnzGzTKfu1PqZls+RnQzi4nq9/OiqfHetRD13/l8AY4ytWnJtbRFre27A4AyE= X-Received: by 2002:ab0:2997:: with SMTP id u23mr14656153uap.67.1607708983621; Fri, 11 Dec 2020 09:49:43 -0800 (PST) MIME-Version: 1.0 References: <160745190172.15620.17081247178872475062@ietfa.amsl.com> <65714d6f-1074-4cb6-a939-6b8ef07e907a@www.fastmail.com> In-Reply-To: <65714d6f-1074-4cb6-a939-6b8ef07e907a@www.fastmail.com> From: "Murray S. Kucherawy" Date: Fri, 11 Dec 2020 09:49:31 -0800 Message-ID: To: Alexey Melnikov Cc: Kurt Andersen , "dmarc@ietf.org" , dmarc-chairs@ietf.org Content-Type: multipart/alternative; boundary="000000000000defc2d05b633eacd" Archived-At: Subject: Re: [dmarc-ietf] dmarc - New Meeting Session Request for IETF 110 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 11 Dec 2020 17:49:46 -0000 --000000000000defc2d05b633eacd Content-Type: text/plain; charset="UTF-8" On Fri, Dec 11, 2020 at 8:59 AM Alexey Melnikov wrote: > Murray will correct me if I am wrong, but I have several comments: > > On Fri, Dec 11, 2020, at 12:37 AM, Kurt Andersen (b) wrote: > > I'm wondering why we should wait for IETF110 rather than having an interim > meeting sooner. Interim meetings are also likely to garner greater > participation since they do not include participation fee. If there are > topics worthy of F2F discussion, why wait? If there are not, then why > charge people to join a pointless meeting? > > 1). All online IETFs this year had "free attendence" option. If people can > afford to pay to attend, they should, as this supports RFC publication > cost, cost of online meetings, etc. But people can attend for free if needs > be. > As far as I know this is going to be the case for IETF 110. > I concur. The fee for virtual meetings is less than half that of the usual in-person meetings since the IETF's costs are obviously lower, but we do need to keep the lights on. For people that can't afford to participate otherwise, there is a fee waiver program available. I suggest that this working group has enough of a work queue before it that having both an interim meeting and a scheduled session at IETF 110 is certainly worth considering. -MSK, ART AD --000000000000defc2d05b633eacd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Fri, Dec 11, 2020 at 8:59 AM Alexey Me= lnikov <alexey.melnikov@iso= de.com> wrote:
Murray will correct me if I am= wrong, but I have several comments:

On Fri, Dec 11, 202= 0, at 12:37 AM, Kurt Andersen (b) wrote:
I'm wonder= ing why we should wait for IETF110 rather than having an interim meeting so= oner. Interim meetings are also likely to garner greater participation sinc= e they do not include participation fee. If there are topics worthy of F2F = discussion, why wait? If there are not, then why charge people to join a po= intless meeting?
1). All online IETFs this= year had "free attendence" option. If people can afford to pay t= o attend, they should, as this supports RFC publication cost, cost of onlin= e meetings, etc. But people can attend for free if needs be.
= As far as I know this is going to be the case for IETF 110.

I concur.=C2=A0 The fee for virtual meetings i= s less than half that of the usual in-person meetings since the IETF's = costs are obviously lower, but we do need to keep the lights on.=C2=A0 For = people that can't afford to participate otherwise, there is a fee waive= r program available.=C2=A0

I suggest that thi= s working group has enough of a work queue before it that having both an in= terim meeting and a scheduled session at IETF 110 is certainly worth consid= ering.

-MSK, ART AD
--000000000000defc2d05b633eacd-- From nobody Fri Dec 11 09:51: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 33F883A0D39; Fri, 11 Dec 2020 09:51:55 -0800 (PST) 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 uxmUMgqfNGpQ; Fri, 11 Dec 2020 09:51:54 -0800 (PST) Received: from mail-pf1-x42d.google.com (mail-pf1-x42d.google.com [IPv6:2607:f8b0: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 1CE1E3A0A42; Fri, 11 Dec 2020 09:51:54 -0800 (PST) Received: by mail-pf1-x42d.google.com with SMTP id b26so7444493pfi.3; Fri, 11 Dec 2020 09:51:54 -0800 (PST) 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=gs7Sqq5LWRV7mF76fH3QBidphQCFIjlfI6P4i7XA/Tw=; b=c+aM+Esev7gtHnwsUA4JgQW1jUkSh+TzTzOvHC4+/tC7A3vhzKYRZcoBbsaZlQ97mL Brsdl5F+Erw0t2umhpHuqy/MHpM/O0v64TvqiN8zjtN714hLL0iAQofQvu46FPZHxPPp JIouTlpv9H53iuwbmAezxHO6dUezqA994cJWFx5cQCzE65NYSRkqqB5sokVMWuAXzsOd cjQkPJZWVEjvDkppnfQjkqNfuKTLmosM4ijByMasqGDTaRhBkboRb/U7xo5uz19ckfOo DV2oBwvMvVIGbq0qAqGGBCZiYgtivexJmlIRgdCZH9b0jJg6Ofq39VuR9CSRsB5LP31G V+vw== 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=gs7Sqq5LWRV7mF76fH3QBidphQCFIjlfI6P4i7XA/Tw=; b=cXEQnvOi/h0uFpKPDUIhLLTJfJ79NaG7/mYCxWrk3V3KfRqxmN2MZSsC6PXFG68sLM rJgSEjbgx3+trGac6XjDK82NG11kF3rh6K2zQUZl9kUdNvOe2RIU9KdBTHZuloV0jEO1 VDnlhzXpUZYAz4+z9jPVomuCucbxnKuKGfX2I8yrB8cY1vlPpI71NSGTugvJr2ASZGsb b3uYNDaI/KqzyQtGV7KnyMIp2arkv6v3iSr0zXTv1woxJlnnTWPs+wtiQWdFefetewbw zsFN1nQjyRvAJ00xty3Wuk5k0iERmNHisliHPzuGh6HuXEpfm2RIesUD6NGZBrl0saJ6 p7EA== X-Gm-Message-State: AOAM533JmKYTMyrV2x7AYUIY51ureLe9+AJwvrM243xvZRRHc4CoeSPt HzoeSxMsPvyaZV84hcHz9IUcqDu2Tco= X-Google-Smtp-Source: ABdhPJyTiVGvxaEXtWrD2YBHEhLhMa5YF9Y3OTQ8BfzU83B99VO8VK3lrMio76U/J87ivuGIETWUkQ== X-Received: by 2002:a63:150b:: with SMTP id v11mr13040293pgl.257.1607709113445; Fri, 11 Dec 2020 09:51:53 -0800 (PST) Received: from [192.168.0.109] (c-24-130-62-181.hsd1.ca.comcast.net. [24.130.62.181]) by smtp.gmail.com with ESMTPSA id h32sm11705630pgl.36.2020.12.11.09.51.52 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 11 Dec 2020 09:51:52 -0800 (PST) To: "Murray S. Kucherawy" , Alexey Melnikov Cc: "dmarc@ietf.org" , Kurt Andersen , dmarc-chairs@ietf.org References: <160745190172.15620.17081247178872475062@ietfa.amsl.com> <65714d6f-1074-4cb6-a939-6b8ef07e907a@www.fastmail.com> From: Dave Crocker Message-ID: <37b1b126-3f12-2cc5-b8d8-a3980920a8cf@gmail.com> Date: Fri, 11 Dec 2020 09:51:50 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.5.1 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] dmarc - New Meeting Session Request for IETF 110 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 11 Dec 2020 17:51:55 -0000 On 12/11/2020 9:49 AM, Murray S. Kucherawy wrote: > I suggest that this working group has enough of a work queue before it > that having both an interim meeting and a scheduled session at IETF > 110 is certainly worth considering. +1 Interims should be saved for times the wg has hit a wall in making progress and needs the greater communication efficiencies of real-time interaction. d/ -- Dave Crocker dcrocker@gmail.com 408.329.0791 Volunteer, Silicon Valley Chapter American Red Cross dave.crocker2@redcross.org From nobody Fri Dec 11 09:55: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 6A4CC3A0D66 for ; Fri, 11 Dec 2020 09:55:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, 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=mtcc.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 LtZoGmwRB9QD for ; Fri, 11 Dec 2020 09:55:52 -0800 (PST) Received: from mail-pg1-x533.google.com (mail-pg1-x533.google.com [IPv6:2607:f8b0:4864:20::533]) (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 143753A0D47 for ; Fri, 11 Dec 2020 09:55:51 -0800 (PST) Received: by mail-pg1-x533.google.com with SMTP id 143so1522645pge.10 for ; Fri, 11 Dec 2020 09:55:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mtcc.com; s=fluffulence; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=OjPUKw5nDThAmMqCQC504axLptzUz5RuBCeNbwpUsyg=; b=VM8G7jnWdb4BaVy50oWN4VhcNQsiS3f2Plcx5mS+jT4k9TqSIg6Uk0nD279PiDuJJA CAV74lh6iNIltdI+b2O3zGue+IcrmrXdfum+cVVybO7TJvNPGa+wVKkl9lV1ykomp2X8 yzbBznYt3t+Aw5vb9GOUvKeQXu0T/qF5/cXTilytFGWvrCrVMSySTT1FFP8OWzp+SI8H kS9txEzHsbkWeCFg4i/mq73H5ndpGbL7SGTbMi2wRzShGtpsiUFvSB0rMY1GNNj37Po6 BxAsWJwcsvuuvaCDwnwLMxPdKss2vTqyLMQKRnDBVU9zUxDkeckH4HrQz5GABnp10U2s uynA== 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=OjPUKw5nDThAmMqCQC504axLptzUz5RuBCeNbwpUsyg=; b=FAD+s5J2NB7LCUztJIzgE95YrCahGuOoEa/he9PSbZIQewf7rLnteWDRc72UD1Mz92 FkhEsQFyyxTj7WJh+XJoYhDW2UZb9fRUSsr9bY2dxIiTyITZlifHeKMRMpg6w5PBRa/i hOeK51tRnToiHiMZEzip2ezFTc0D6UXuYRnbZ8b5ilO5BF6XmFhVAsapFX4RW9SFhwtF x97vi/qVKoMf0z3VhmN+gnWhpKs7JrIVTbbttwYN+EaGsE2oOOfHI1HY/HCHLiCpwh1r Xlqx4QNBXy6YHqb6H2oR2DYIeRmzGls/eucp0OZt7kNb2JQZN6lHsY7QQ8ZGs8kQR+/m tsBg== X-Gm-Message-State: AOAM531KxsjZ4h4TBwLJLJfwlkkAoLiZJC9ZoH+PD4Sh5PUY3L6sSghU FaUbTNxuauzrJuxpG4/KjgA6i6jlm7LhXA== X-Google-Smtp-Source: ABdhPJyXa3dmvW8+Lt85JHpyZZRpQeVanrL73fjh2rOd66/1PA08n/gIyXHu2WAhop056diVfykXSA== X-Received: by 2002:a63:f84d:: with SMTP id v13mr12915033pgj.234.1607709351070; Fri, 11 Dec 2020 09:55:51 -0800 (PST) Received: from mike-mac.lan (107-182-41-154.volcanocom.com. [107.182.41.154]) by smtp.gmail.com with ESMTPSA id g5sm11159855pfr.87.2020.12.11.09.55.50 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 11 Dec 2020 09:55:50 -0800 (PST) To: dmarc@ietf.org References: <160745190172.15620.17081247178872475062@ietfa.amsl.com> <65714d6f-1074-4cb6-a939-6b8ef07e907a@www.fastmail.com> From: Michael Thomas Message-ID: <8ff51cd7-6138-d534-c535-86fba9c6b56d@mtcc.com> Date: Fri, 11 Dec 2020 09:55:48 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------1EF501321AFAB599E2D8A316" Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] dmarc - New Meeting Session Request for IETF 110 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 11 Dec 2020 17:55:54 -0000 This is a multi-part message in MIME format. --------------1EF501321AFAB599E2D8A316 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 12/11/20 9:49 AM, Murray S. Kucherawy wrote: > > > I concur.  The fee for virtual meetings is less than half that of the > usual in-person meetings since the IETF's costs are obviously lower, > but we do need to keep the lights on. For people that can't afford to > participate otherwise, there is a fee waiver program available. > I know this is the wrong list, but what about people who could afford it, but don't want to afford it? It's not like I'm making money from participating and that it's just a cost of doing business. These discussions ran into the trillions of messages on the ietf list so i was never able to figure that part out. Mike --------------1EF501321AFAB599E2D8A316 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit


On 12/11/20 9:49 AM, Murray S. Kucherawy wrote:


I concur.  The fee for virtual meetings is less than half that of the usual in-person meetings since the IETF's costs are obviously lower, but we do need to keep the lights on.  For people that can't afford to participate otherwise, there is a fee waiver program available. 

I know this is the wrong list, but what about people who could afford it, but don't want to afford it? It's not like I'm making money from participating and that it's just a cost of doing business. These discussions ran into the trillions of messages on the ietf list so i was never able to figure that part out.

Mike

--------------1EF501321AFAB599E2D8A316-- From nobody Fri Dec 11 10:04: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 85DBA3A0D6F for ; Fri, 11 Dec 2020 10:04:17 -0800 (PST) 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 uzMkB-z0Tr0m for ; Fri, 11 Dec 2020 10:04:16 -0800 (PST) Received: from mail-vk1-xa2b.google.com (mail-vk1-xa2b.google.com [IPv6:2607:f8b0:4864:20::a2b]) (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 1AA0E3A0D66 for ; Fri, 11 Dec 2020 10:04:16 -0800 (PST) Received: by mail-vk1-xa2b.google.com with SMTP id t16so2272953vkl.10 for ; Fri, 11 Dec 2020 10:04:16 -0800 (PST) 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=rHCIGd71SIxVEk/MGx4kkZwaDqUccLArhaRTO/h51mM=; b=pJohVjV78fXwXRuCH97aa6IJi/kYAKIc9+zcR7W9jTcFl+5pcx+gyBElobPlhw0lU4 0kH029Dc5azT7pINwlbbWs8fwmHM58N9jejAohIZGXrFdRtlMtvPf1yUOseJMgUDb1dR VLEYindPrqDl1uKt2lvCWPseY+PzLnU0ywsnG19bnOoaj9M+ajCQ/btndE/GTiajc/cx hxfyCIgVz/w1WByK9xid9j3mpD3qzsyqJSXu7XKro7Cj/prkqTNldQLB/OJlybTs0QFM wCI+WOtK7/hTcHHnCsvZaX/i+RcDcxgTACyN9C1gXZ7sZnwWe05eA5frNiKmMPPB7Ro9 4egA== 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=rHCIGd71SIxVEk/MGx4kkZwaDqUccLArhaRTO/h51mM=; b=R/f0TNM291lau3LOrlvrUTuQAKvT2b/CEBT69iUe58ssBF+OxKr/z5jouYVTLoPSs5 sM95ZpZNzfDCw3Kir88xegfSBbkQvC3VZfPpvOZvG47cYoqzcl4jgRHDUGXWMXRCG58p Um1MF4DNAGlJg1h5N3bIiZCefyFJWHQ0H/WsQbNIbTAJtK5GDox3ezCxQMm7pFvbKBmI 79OfeU7+f4o4/x2jSK3cWhtbiSgA3lWSHlAI4r6kOU4MUStSKhkBiuw5wDKcOV7WWqE9 Menj42WUQDlO/49hojFsqWcwhWve70ERh8CfhGe5lQJzVx8FHQclWxhlf588RCCBFAV0 Ctww== X-Gm-Message-State: AOAM531wcD98eNt5x3whxbO91YC29SY5CNDVaU+1iqtktLjuRKwk9+6O vKa3Hky2x3Gfmaog7KGg0Qw8MrV62PeOMnkF0ItKwlD5RSQ= X-Google-Smtp-Source: ABdhPJx4XA/jfSCErNLQTuqV0AT1OAWlcBHXj1BlzGdr7w24GBaOB5axHtgPI0twerIGHSp/5WOWJOGetQifTLgKKhY= X-Received: by 2002:a1f:36d4:: with SMTP id d203mr15272695vka.22.1607709855050; Fri, 11 Dec 2020 10:04:15 -0800 (PST) MIME-Version: 1.0 References: <160745190172.15620.17081247178872475062@ietfa.amsl.com> <65714d6f-1074-4cb6-a939-6b8ef07e907a@www.fastmail.com> <8ff51cd7-6138-d534-c535-86fba9c6b56d@mtcc.com> In-Reply-To: <8ff51cd7-6138-d534-c535-86fba9c6b56d@mtcc.com> From: "Murray S. Kucherawy" Date: Fri, 11 Dec 2020 10:04:02 -0800 Message-ID: To: Michael Thomas Cc: IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000cff03805b6341e39" Archived-At: Subject: Re: [dmarc-ietf] dmarc - New Meeting Session Request for IETF 110 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 11 Dec 2020 18:04:18 -0000 --000000000000cff03805b6341e39 Content-Type: text/plain; charset="UTF-8" On Fri, Dec 11, 2020 at 9:56 AM Michael Thomas wrote: > I know this is the wrong list, but what about people who could afford it, > but don't want to afford it? It's not like I'm making money from > participating and that it's just a cost of doing business. These > discussions ran into the trillions of messages on the ietf list so i was > never able to figure that part out. > To answer your question, I'll offer this text which was on the fee waiver page for IETF 109, but you're right that this is really off-topic here so further discussion should be started on ietf@ietf.org. "We understand that not everyone can afford the IETF 109 registration fee for a variety of reasons, including issues with income, employment status and employer support, and we do not want any of these to be a barrier to participation. If you cannot afford the registration fee then please take this fee waiver option to ensure that you can participate. We make an unlimited number of fee waivers available and we do not ask you to explain why you are taking the fee waiver option or make any check on eligibility as we operate on a trust basis. The information you provide will be confidential and will only be used for the purpose of allocating fee waivers." -MSK, ART AD --000000000000cff03805b6341e39 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Fri, Dec 11, 2020 at 9:56 AM Michael T= homas <mike@mtcc.com> wrote:
=
=20 =20 =20
I know this is the wrong list, but what about people who could afford it, but don't want to afford it? It's not like I'm= making money from participating and that it's just a cost of doing business. These discussions ran into the trillions of messages on the ietf list so i was never able to figure that part out.
<= /blockquote>

To answer your question, I'll offer thi= s text which was on the fee waiver page for IETF 109, but you're right = that this is really off-topic here so further discussion should be started = on ietf@ietf.org.

=
"We understand that not everyone can afford the IETF 109 registra= tion fee for a variety of reasons, including issues with income, employment status and emp= loyer support, and we do not want any of these to be a barrier to participation. = If you cannot afford the registration fee then please take this fee waiver option = to ensure that you can participate. We make an unlimited number of fee waivers availa= ble and we do not ask you to explain why you are taking the fee waiver option o= r make any check on eligibility as we operate on a trust basis.

The information = you provide will be confidential and will only be used for the purpose of a= llocating fee waivers."

-MSK, ART AD

--000000000000cff03805b6341e39-- From nobody Fri Dec 11 10:36: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 D4C3B3A0C2F for ; Fri, 11 Dec 2020 10:36:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MHsJNwNqI0wl for ; Fri, 11 Dec 2020 10:36:41 -0800 (PST) Received: from mx0a-00143702.pphosted.com (mx0a-00143702.pphosted.com [148.163.145.77]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A1353A0B77 for ; Fri, 11 Dec 2020 10:36:41 -0800 (PST) Received: from pps.filterd (m0156893.ppops.net [127.0.0.1]) by mx0a-00143702.pphosted.com (8.16.0.43/8.16.0.43) with SMTP id 0BBIVV4W032420 for ; Fri, 11 Dec 2020 13:36:36 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.com; h=from : to : subject : date : message-id : content-type : content-transfer-encoding : mime-version; s=20190412; bh=cS5XC6g2lbHt6vBS6lWzX+2jqDmlFFv+vu0zewRoi8c=; b=K6+woyRztkmT2oArujgO4Jm7oVGm50ttN8if9rrAbQvVcXkCrXUmquIaoAhbca/PhFq7 HupaK8dLAfp+Uqnawsdwg1kp6a15hHNqj4Kw+D8emVx19IFZLShEr7M3H413r5iZA0tA 07pwGQmmNzrjL/oOb7fcjil4fwEQIRcCd0yDTF4ScmVUtaGNpAFol+ztGWpikqakXkRa zopnLtugQJ2+RtYFIrozG6Vv0jP1u7U5B4v76IUK1v0BP/6MCltG1IsEFZ5EQV6Jw83R VOmnY3p1qbXR8JMBCywgO3M8swhwe5/lPomqxXkDGjAbasnprC/w5iPf7Ap2DHsICgag Dg== Received: from copdcexc34.cable.comcast.com (dlppfpt-po-1p.slb.comcast.com [96.99.226.137]) by mx0a-00143702.pphosted.com with ESMTP id 35bp93gf3m-11 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for ; Fri, 11 Dec 2020 13:36:36 -0500 Received: from copdcexc33.cable.comcast.com (147.191.125.132) by copdcexc34.cable.comcast.com (147.191.125.133) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1713.5; Fri, 11 Dec 2020 11:36:29 -0700 Received: from COPDCEXEDGE01.cable.comcast.com (96.114.158.213) by copdcexc33.cable.comcast.com (147.191.125.132) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1713.5 via Frontend Transport; Fri, 11 Dec 2020 11:36:29 -0700 Received: from NAM12-DM6-obe.outbound.protection.outlook.com (104.47.59.176) by webmail.comcast.com (96.114.158.213) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 11 Dec 2020 13:36:17 -0500 Received: from MN2PR11MB4351.namprd11.prod.outlook.com (2603:10b6:208:193::31) by MN2PR11MB4206.namprd11.prod.outlook.com (2603:10b6:208:188::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3654.12; Fri, 11 Dec 2020 18:36:16 +0000 Received: from MN2PR11MB4351.namprd11.prod.outlook.com ([fe80::7ca6:b482:a6b0:4d42]) by MN2PR11MB4351.namprd11.prod.outlook.com ([fe80::7ca6:b482:a6b0:4d42%7]) with mapi id 15.20.3654.017; Fri, 11 Dec 2020 18:36:16 +0000 From: "Brotman, Alex" To: DMARC IETF Thread-Topic: Clarification of Subdomain Reporting Thread-Index: AdbP572VQsVJ89zAQIeNUCxVu9wIqg== Date: Fri, 11 Dec 2020 18:36:16 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=comcast.com; x-originating-ip: [2601:43:101:380:2457:570:6fd4:fb95] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 41bf154b-00c2-4126-116d-08d89e03a553 x-ms-traffictypediagnostic: MN2PR11MB4206: 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: b+j88vPYBjdMRXuc7fUtyuBaP3UWS5Lo7rVVAobjB+pQZ0ujPwTzKYkySrlqc8br8vX9KXyabOtnbq83gw88NJfQumDEm43UcackNxV+gxVKG1+BIPb9FjmIAEKW9OLAWtbo+eylace67vQ3MenGzyXptQg6Be48g7JqzTvxXENSGa+zfyLO5hb0KX8EsYkJurd3qeD7vcDWK8ket0JDRSjfeccJE/+u0GUOF5ZBGvVUSk1OHFhty8or1UJ1ujjw4bhesfTFCmXcaM4F/ASJk9m+ztkuy7OJMz0hBbJqDHheolLn9x6QydOPSNxnQwGPWT86gZDdZNwm90LxE49Ucom94ugrTDfVMU1PYUwrZoayoxjVyinjeKeHy9bclawr9+pluYDSPqS7vwsKjenS6w== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR11MB4351.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(39860400002)(346002)(366004)(376002)(136003)(396003)(9686003)(71200400001)(3480700007)(316002)(55016002)(478600001)(6916009)(966005)(64756008)(66476007)(66946007)(6506007)(52536014)(33656002)(86362001)(186003)(7696005)(8936002)(8676002)(66556008)(66446008)(2906002)(4744005)(5660300002)(83380400001)(76116006); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: =?us-ascii?Q?FZeKLMALlhWTc+Fs2boDIcQ4WyB4M+6pBH44buao6YsIrbUNWhg8EeBRqnTL?= =?us-ascii?Q?DP0uoMt8T1IytaYeXLDIfPPqAhm6sIQDpkauD9dRj8qBvIho8UlynnYR5NkO?= =?us-ascii?Q?3qEHM0oTMSeMNj3F6ODiJimOWbkafePr6jtECloxWHTVNMVveux/GA8XMSVS?= =?us-ascii?Q?4ZSglKyzuy4D7qTPH+MGCAjrXlYU3jeZPHGLAtaJDbc+RvGq5jBSjiL0hXHH?= =?us-ascii?Q?pnCO1/9+L2zDG+GYFUtlnn5rgDal9IZIuh8xTcMOVSwGxVMXknLMLdPwV4ZX?= =?us-ascii?Q?YTmDxkAC8QskvVXveauT/LX199lHtd0HZOUX36vSlOQdNzasTjhqdx+XUqfP?= =?us-ascii?Q?fUD1kVc1cGaA465JTk6bTiIOuqmAHMcmOMyp9edDFnIvaJhQEkqIJxMHV9N8?= =?us-ascii?Q?RrqHhdmm0uOvHUPKkgXuTfyF2OL5oNfBIzOOmHFXg2ud1+hVRenunRIZ6nId?= =?us-ascii?Q?SeR78PgOjJxBi92rS1399qtDC/q2b6/i3jGWv2d0OgMT+2J6qRfD1vrpk2pF?= =?us-ascii?Q?FTwFDvCWTXAx9UXPfMYAtO9mXQO0tOTSEzQOuFYS5Svh5dLu7mCa/fDrW4CC?= =?us-ascii?Q?nCp8lnVb3UTiGnCJGXqC0oFTGaQiu1W5iXBNMtU2lcQB9t3w39cQuVILNrRx?= =?us-ascii?Q?QLdspL3Ov9fClru+oEkkES/d3w1hWf8hXgLQbSez03NFtvc0WNyQ/dofrAmF?= =?us-ascii?Q?uIaMxnNpv8Yl1U9dwZCpBVCwa7tIEhlsn8Vs4VPqO0/m/LkhgrXY2LQeLFIE?= =?us-ascii?Q?oqNa6y8FXz3K0545zpErh8xMQGOWk9V2hQ7cwfReFjIAVDbLz8iYVqDpzevZ?= =?us-ascii?Q?OguA78IMTw8EGp83lGG+I5UxB2nPe5aqSIhynD+hPmdKWKjB6Saynb8sWfQC?= =?us-ascii?Q?ER5jCB4zXBmsoJbkCgXMh7/GKma8WHOmrfBFdB4jkNNjy5W+mg2VPCK/AWq1?= =?us-ascii?Q?6GfusA/5mKk+gE7Td42xiFkMXScE0o6mq28Bn82OVMP/Kv4Alw2d3PYMW+7o?= =?us-ascii?Q?OS/UpbLBRC7XXWrr+dbBZz4ktFsEkK3qpB+Bs2h6AxGoBrU=3D?= x-ms-exchange-transport-forked: True arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=TolwY4ojgnLZHzirNg9D5349/yaeM1/eiuJ0UBtQIMEjZrRAbf1NGBxxrx/+lsq83xGybbtuYZvq+GsO83j3Kr7qfsFZ+N11kre6Mw9sklo9ugl/qyZeWvK3IgR2ePxS23weE1qNhM/RdmB46/JlUZV6xQ5eNyJL1rBesMlKsdxIb5+oILRK+JXhpUQIEhryEs0UH7n3L30LfbEZSj34jTQHZuVHNBjS0lWAcx+6G0Oi2Jj5qFHU8aXTCED4VwOqboRSc0tjMkBfcJmQ2XroIhFh0YBCjqiHZcSS3YUVeWmupdmQGMqPZy/lqs4Tu47B6PKFrEXKlQi8b+SFfglplA== 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=p6uOldwUhxSzOMkVCi64pYP8JcxDf0LUq0YlWhXV080=; b=ZfrWqViE88fPoSjx359sy/ctyk9aDpGdGGE+YoOFK3elxWvFaYf4kUq8cmnl06s4rcRDY5tU0xpWWrX3QHuU2gwfjZQaFZyyE3gYxogeRLyOJ4xto1x2p+2V2kjJMuSjS9uLJXVc1C6cQdUlCoX24Ieyyo+T8BmLpOHe8I1oG/9nDthw8oewLHhJcbOofPFiyUgTxaBFkMe7mICvVigKQHBLNLRwQlO7MyM8PfENJHD+qsv2cfUO///CvBJuC4OL5+rBceWwYl3xX3krRvCgibZPn5Sm1ZXU7wFhuwe676eRRzhv2JZGM642iKEAtsohQm52sr1g7Lnfiu1ijSf9WA== arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=comcast.com; dmarc=pass action=none header.from=comcast.com; dkim=pass header.d=comcast.com; arc=none x-ms-exchange-crosstenant-authas: Internal x-ms-exchange-crosstenant-authsource: MN2PR11MB4351.namprd11.prod.outlook.com x-ms-exchange-crosstenant-network-message-id: 41bf154b-00c2-4126-116d-08d89e03a553 x-ms-exchange-crosstenant-originalarrivaltime: 11 Dec 2020 18:36:16.8130 (UTC) x-ms-exchange-crosstenant-fromentityheader: Hosted x-ms-exchange-crosstenant-id: 906aefe9-76a7-4f65-b82d-5ec20775d5aa x-ms-exchange-crosstenant-mailboxtype: HOSTED x-ms-exchange-crosstenant-userprincipalname: oY0R5TOT4mdW4Ba2S0ZlaJMj6yE7wRIXT+2SfjKVeiyDULE5Wy0EMCsehyoPAueL8H4UQ1f9dBZjVs0oeySeYSqSC1jZ2nygDU/uel+oZPM= x-ms-exchange-transport-crosstenantheadersstamped: MN2PR11MB4206 x-originatororg: comcast.com Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Forward AAETWO X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.343, 18.0.737 definitions=2020-12-11_05:2020-12-11, 2020-12-11 signatures=0 X-Proofpoint-Spam-Reason: safe Archived-At: Subject: [dmarc-ietf] Clarification of Subdomain Reporting X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 11 Dec 2020 18:36:43 -0000 Based on a discussion from last year (https://mailarchive.ietf.org/arch/msg= /dmarc/YoHhhaAfwRjbd8aq4fiV6xU1ifw/), there was a request/ticket to clarify= the language in the document. >From https://tools.ietf.org/html/rfc7489#section-7.2: * Data for each Domain Owner's subdomain separately from mail from the sender's Organizational Domain, even if there is no explicit subdomain policy Seems to be lacking clarity. I took an initial attempt at clarifying that = bullet, but welcome comments: * Within the same report, subdomain data should be separate from data for the Sender's Organizational Domain. This should be true even when subdomain does not have their own explicit DMARC record Does that seem reasonable? I'd suspect we should modify the sample report = to include a subdomain as well. -- Alex Brotman Sr. Engineer, Anti-Abuse & Messaging Policy Comcast From nobody Fri Dec 11 11:38: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 9465D3A0CC3 for ; Fri, 11 Dec 2020 11:38:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.851 X-Spam-Level: X-Spam-Status: No, score=-1.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iecc.com header.b=VjI0Gxfq; dkim=pass (2048-bit key) header.d=taugh.com header.b=mnCUqv+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 MxFYuhn-zjtv for ; Fri, 11 Dec 2020 11:38:47 -0800 (PST) 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 577633A0D9B for ; Fri, 11 Dec 2020 11:38:46 -0800 (PST) Received: (qmail 56520 invoked from network); 11 Dec 2020 19:38:46 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=dcc6.5fd3cac6.k2012; bh=I1fKNwqzPqycN0pUFsRjZveqr3ykBZ7hWK8hvHDKI5w=; b=VjI0GxfqQevUinsasYOeLAukRhbyX7/1lIrCCBXFZ7zNfPW5BgjR7xQW3OKf6r9WOvmuNUD1E8bBvTPj0Xbw8vVYSjNg2jKW1HVQT1Gp/lR6zeVOSubMr+z9yv2lM5o3FGqr2BiH4y7u8+cp5GQ1Pef8afMn+j/GziKJ7T4SMrEzvMWW+K5vxiwNClCyzF9dwPd3QIcGeZJxHr+hoAXhz1fOJ3jDUhjMXPlVpRW0TrkFtkfB0to81f4/Z9PjQGSqrKLwgb9P9xqpXyBnvAGewBy6bA/LtBeny+nCRD3iEb6+0tygB5Wu3+AkXGoFv01n5dsX8bVBKvXJhRS68I/W2Q== DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=dcc6.5fd3cac6.k2012; bh=I1fKNwqzPqycN0pUFsRjZveqr3ykBZ7hWK8hvHDKI5w=; b=mnCUqv+AAPP3KIrT/EIXvH98Jo25dOBDHKrZz6ecUSuTzxZSd6ZXyhIpvdbvcUCcB6p5AAGa8c9OhY7qVpo1GmaQ+ByCU/AZaNWfkeHSU8aVbn0gkNIaGPEpu6kqfDJZkw6Yh4+soWTqxUq/AwZz4JDprXM37zJtAPdoqeJKH2bPSXW0mA5ZlxsM+ZmSD5epH+xBHe+SElBCMm6eHx+1E5amyZJs/xy7RDOl963IuuxHrC/FsU2JZMDxl68Tn7M+TDXrbvE/g1C9f2K3KsGGzGM3dK2tPUpc5TqUDrIhmh1z94bAO4Idu7JTPPvhhbR5KjmcKFFwBNJDn0WU1cThzA== 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; 11 Dec 2020 19:38:45 -0000 Received: by ary.qy (Postfix, from userid 501) id 63466297AE5D; Fri, 11 Dec 2020 14:38:44 -0500 (EST) Date: 11 Dec 2020 14:38:44 -0500 Message-Id: <20201211193845.63466297AE5D@ary.qy> From: "John Levine" To: dmarc@ietf.org Cc: Alex_Brotman@comcast.com In-Reply-To: Organization: Taughannock Networks X-Headerized: yes Cleverness: minimal Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] Clarification of Subdomain Reporting X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 11 Dec 2020 19:38:50 -0000 In article you write: >Based on a discussion from last year >(https://mailarchive.ietf.org/arch/msg/dmarc/YoHhhaAfwRjbd8aq4fiV6xU1ifw/), there was a >request/ticket to clarify the language in the document. > >>From https://tools.ietf.org/html/rfc7489#section-7.2: > > * Data for each Domain Owner's subdomain separately from mail from > the sender's Organizational Domain, even if there is no explicit > subdomain policy That would be a change to the XML report schema. It'd change as I show below to force a separate row for each header_from. That's a somewhat incompatible change, so I'd want to be sure we agree that it's a real problem that's worth changing the report format. I suppose if we do we should encourage report consumers to be prepared for old and new formats. R's, John Old: New: From nobody Fri Dec 11 13:23: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 A84C73A0EF6 for ; Fri, 11 Dec 2020 13:23:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pjXE2jpTG8cZ for ; Fri, 11 Dec 2020 13:23:43 -0800 (PST) Received: from mx0b-00143702.pphosted.com (mx0b-00143702.pphosted.com [148.163.141.77]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 265203A0EF4 for ; Fri, 11 Dec 2020 13:23:43 -0800 (PST) Received: from pps.filterd (m0156896.ppops.net [127.0.0.1]) by mx0b-00143702.pphosted.com (8.16.0.43/8.16.0.43) with SMTP id 0BBLKd1g026730; Fri, 11 Dec 2020 16:23:42 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=20190412; bh=59t0Cppppup/gzRySxbOMpYgYMX0vAIo7KaDmu28EHE=; b=ClrX4o6lBOAbLtsbZzgXharWRY0+Z4juFDALGhR0QKhIsZaF4NHArGHXad5bRUQbcBDG gvj99R2geAYk9ITXY+cIeQ6GdIIYNhZx2aQmjq5b0cKgtmysCrfcEMMB9IYR2xsW0/Fd il4WFIFxiiyAjR5O/SlNKT0YSZAg+9ldSN3zJfgxN4H9gZEYziitI3fbJgQr66boIwm0 Tlc6W9FYQ03uNgPnykvnV838FQrSD4xNs7H99cSsEsQJ7u/Pxpt+zzKyypDDs09CHZ+a n2NPS6+HdsCOzjhmPm8/UKavpfo83ISAV4iRtWpyIXRpvA0CXGE9N8QfU3NbZMrit8mq mA== Received: from copdcexc37.cable.comcast.com (dlppfpt-po-1p.slb.comcast.com [96.99.226.137]) by mx0b-00143702.pphosted.com with ESMTP id 35br2br8yd-10 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Fri, 11 Dec 2020 16:23:42 -0500 Received: from copdcexc33.cable.comcast.com (147.191.125.132) by COPDCEXC37.cable.comcast.com (147.191.125.136) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1713.5; Fri, 11 Dec 2020 14:23:37 -0700 Received: from COPDCEXEDGE01.cable.comcast.com (96.114.158.213) by copdcexc33.cable.comcast.com (147.191.125.132) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1713.5 via Frontend Transport; Fri, 11 Dec 2020 14:23:37 -0700 Received: from NAM02-CY1-obe.outbound.protection.outlook.com (104.47.37.53) by webmail.comcast.com (96.114.158.213) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 11 Dec 2020 16:23:16 -0500 Received: from MN2PR11MB4351.namprd11.prod.outlook.com (2603:10b6:208:193::31) by BL0PR11MB3330.namprd11.prod.outlook.com (2603:10b6:208:64::30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3654.14; Fri, 11 Dec 2020 21:23:15 +0000 Received: from MN2PR11MB4351.namprd11.prod.outlook.com ([fe80::7ca6:b482:a6b0:4d42]) by MN2PR11MB4351.namprd11.prod.outlook.com ([fe80::7ca6:b482:a6b0:4d42%7]) with mapi id 15.20.3654.017; Fri, 11 Dec 2020 21:23:15 +0000 From: "Brotman, Alex" To: John Levine , "dmarc@ietf.org" Thread-Topic: [EXTERNAL] Re: [dmarc-ietf] Clarification of Subdomain Reporting Thread-Index: AdbP572VQsVJ89zAQIeNUCxVu9wIqgADX68AAAOUqhA= Date: Fri, 11 Dec 2020 21:23:15 +0000 Message-ID: References: <20201211193845.63466297AE5D@ary.qy> In-Reply-To: <20201211193845.63466297AE5D@ary.qy> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: taugh.com; dkim=none (message not signed) header.d=none;taugh.com; dmarc=none action=none header.from=comcast.com; x-originating-ip: [2601:43:101:380:2457:570:6fd4:fb95] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: b3ca6972-ca9e-411c-99d5-08d89e1af8fc x-ms-traffictypediagnostic: BL0PR11MB3330: 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: w0KkcajQVX1eztOVBDdrK2Kbiut2lwfd2kibawvYc6LnBDxiKGkMuEcMxk+U+CS6EakPNgfxd2iyC3i9DhCMxaBDjbyu/Lnkee18UwSXaKBbzF90C8kXl/ZZT8VtoruO/tfPvjWcIeXcqhv8apiJiZUczVsIXq4Klcnap0TPUjZx5CORHJp2gSxMCKaVFHsZvpm2N1b+v3s239qmp+mgVBkZ+oAcdMU3tgqR9HzoYvsiWbZVBApu6StGn9Ea+SsXBxMjyexOFPLuvOSu5Ib1b4/UFBIAxbcY33rzh4v6Jyys5/KV6vk7Csq6E9mXJR+VHuzcSyDzMTG3QOly/zQlClBOZoX92SCDxBO4i5NFIlwMhbl024leqlaXz7Rzwb1c/8pPdLKWlCGUZNSCZBDpcA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR11MB4351.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(346002)(136003)(376002)(2906002)(64756008)(66476007)(66946007)(66446008)(76116006)(66556008)(8936002)(53546011)(6506007)(52536014)(86362001)(508600001)(110136005)(186003)(55016002)(83380400001)(5660300002)(9686003)(33656002)(7696005)(966005)(71200400001)(45080400002)(8676002); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: =?utf-8?B?Q3NBMlg5V2ZndE4zZGo2ZHBmSVVKdVVkQjc4SThvVXpPRGtnakROWFp0K29l?= =?utf-8?B?ejAzWEpXZHdJU0JoUjJRcnBPWFd2VXVYRnRUNHRXeW9GV3AvTGJsUHAxQndk?= =?utf-8?B?dnBlZERqMmxjMWlZaXp5QXRRRDdIVHBQWk05am15dkxnVnNVckdVcUhhdG82?= =?utf-8?B?bzd4b1ZIMkMzWVRQSHdpcUNHK0lGMnJrZmpWV2ZtWUZ5bVZBbE04cGxVWXlT?= =?utf-8?B?Q29HU21RVGllL3U1Y1VWbjNaMXBtTEdwajQva2Fha1l3L0w3RjBCUFZUNTg4?= =?utf-8?B?b3RtQlg1a2lrZWlVUEJmTVdFY2hIRWRYV1NRbmFUdHcvbUc4dm9LS2JGdDBW?= =?utf-8?B?UjM2NXdkTEdsOS9xbnNqQmdzTURrQmNQY3pGNi9DMHE2OS9ORGJaZUM3dHVm?= =?utf-8?B?YWM1WXU5elVZUGZPeXJJcDgvVCt0dU1tQW9TbUZQTjFuVGJuNzhsRDFXazAw?= =?utf-8?B?OU1QeG9FanQ2TFVKVU43MGNJc2wyVkcwZVpmaUxFdlNVWkVRNWVRTDFLOVBi?= =?utf-8?B?UVFhODdxOGc0SHlUUTUzQVdKUHpYZlJ6QitMMCtQQ2ZPUE4zY0pmWHpGbkty?= =?utf-8?B?d05zYjVEbG1zQkJiaW1PeXAySHZFU1VlbFUxZzhDblVQSGFSbjVJb3pEWnNB?= =?utf-8?B?Nk1tRUtkVTNjOHF5cDc5c2lOcWVBRk9lcTZYbnVkYXdCVm1ENmJwa2pENzhv?= =?utf-8?B?RmdoMmljYVdwUUd3MHdud3NUSDRXS2hYSjkranZOcHJ0ZzdsMjBkOXZiSEZR?= =?utf-8?B?NjF2WGxzR1R4R2lGR0hMZ3Uya0k2Z1dzMElPY2FxbktGZ2t3K3hxQm5TeUpr?= =?utf-8?B?U0pUT1YvMCtwQVNncmNFTW9pWk43aFB4UkFOK2tHUnhFNExCalpxcVZVN1BD?= =?utf-8?B?REVYR0tKZ3dKOGl3YWFOYmJ3a0hOUFliSkIzbUUrMmJYN29USEJpMjV1ak9m?= =?utf-8?B?L2ljOXdUYTEra0N1V2hPdExGaEtIci9GOW5XSnBzVE1Zc1htcmU1OGpuTDZp?= =?utf-8?B?cjlCcS96Mk5HaHJvZXZ4WDZpdlhmWVF2bmV3ME05YzV0RXZ4elRneThVeTA5?= =?utf-8?B?K3VQWTlTczZkSFZMMVF0VVZHSS9ZQU1uTXFITCtiRi9DL3VtR3lPYUdHYVg5?= =?utf-8?B?d1BuUDg3K2JiVjBQWlFOMW5MOGdhSk5ycTJjYUs0SHNKallzbUxhMmIwMGx2?= =?utf-8?B?dmlZYzhDQnlOTytrV3l0TFp0ek9xdFZTNGNzQndPRFZRUE1UYXpyUjJsclNG?= =?utf-8?B?TDRiUm5FRUVuSmhWTm5FRDFCUUdFYzBzdEx6cC9jRTlQU3dBcXViQ0R5Z00x?= =?utf-8?B?WmF4VEtVSGRDbU53ZkFhMUpQMkxyQk1oTFFpMXRHcktMZHZVQjMvSUswM2x0?= =?utf-8?Q?AD4v8MkC/Zt41JOBhvHNTLkC3jOluQuo=3D?= x-ms-exchange-transport-forked: True arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=KLxHmqrPONDP1TPSQaOBVFRbqYGtnKAebyjGr5RWyj9vOyNnwCD0i7gqgF3ehwUVq1+RGD+S8RBl119ThYQGN2mTLucY6BchlqSm6Sal6xvicGyxNISYmlbaEah6qjKOgF8IlWKWRj6re7nBEvGfIwVb6ZqALfHcbCQj9QG0e0qIZzdJBaBw0pPgszkZ1V/Lm9taq+xuXmJ139TJWLGb6BGTQPD4LycDSmGW4j+Tk+k8yzsq/A+iftj/VbyPTlJk4XTqduK1sI8iuJtBZS6VTqii8g2sU+NNXH7IsWG1TVM6Mo+attU8yA3y2D5NG6SdVVvCgQRrS1H9rEbFONuYAg== 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=pUFC3leIctOM6XYn0OA9+/lO+n0AjaS1H9KgfqDwBF8=; b=SmUEFAljpF7UJuDELGBzgg3Q325738nVUlhu1zF0FtNkmGqEu/QwM2Uk1Gp84HnfhKckDoc2ucWSx2KapJgIiQ6fzFGyG37j+bEnWxgBhuUr78xocLZyPEnXvXhv0aw93VzpUAks+NcGZs22E139NzZ9a+MkbzscEKWqCvNrQK+y7HWZ65849Uf/86yM/zThBffKAnoDkh7+4J6nHBLVGCInkJtyzd30XGErMD8ciycqaJHznqWAmkJLMA2JpAUrV2Lt/8hZRyPxp4ZcixVdAKf0jLLef97eVEIO2v/K/eWX77JydyGd809EKWcZUPT7pn1LWTmVgC3FGc1bDjbEaQ== arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=comcast.com; dmarc=pass action=none header.from=comcast.com; dkim=pass header.d=comcast.com; arc=none x-ms-exchange-crosstenant-authas: Internal x-ms-exchange-crosstenant-authsource: MN2PR11MB4351.namprd11.prod.outlook.com x-ms-exchange-crosstenant-network-message-id: b3ca6972-ca9e-411c-99d5-08d89e1af8fc x-ms-exchange-crosstenant-originalarrivaltime: 11 Dec 2020 21:23:15.5078 (UTC) x-ms-exchange-crosstenant-fromentityheader: Hosted x-ms-exchange-crosstenant-id: 906aefe9-76a7-4f65-b82d-5ec20775d5aa x-ms-exchange-crosstenant-mailboxtype: HOSTED x-ms-exchange-crosstenant-userprincipalname: GP/tpAqtiq+Ry3WUtlZ68tS8n05DChg28Ezjjqon9GEdw2d9TgXm0q5UZtjig72PcsefP+CQSbVqeS1OerVEa3jLQoX33RIZ/OkpMqjgY8s= x-ms-exchange-transport-crosstenantheadersstamped: BL0PR11MB3330 x-originatororg: comcast.com Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Forward AAETWC X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.343, 18.0.737 definitions=2020-12-11_06:2020-12-11, 2020-12-11 signatures=0 X-Proofpoint-Spam-Reason: safe Archived-At: Subject: Re: [dmarc-ietf] [EXTERNAL] Re: Clarification of Subdomain Reporting X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 11 Dec 2020 21:23:45 -0000 DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogSm9obiBMZXZpbmUgPGpv aG5sQHRhdWdoLmNvbT4NCj4gU2VudDogRnJpZGF5LCBEZWNlbWJlciAxMSwgMjAyMCAyOjM5IFBN DQo+IFRvOiBkbWFyY0BpZXRmLm9yZw0KPiBDYzogQnJvdG1hbiwgQWxleCA8QWxleF9Ccm90bWFu QGNvbWNhc3QuY29tPg0KPiBTdWJqZWN0OiBbRVhURVJOQUxdIFJlOiBbZG1hcmMtaWV0Zl0gQ2xh cmlmaWNhdGlvbiBvZiBTdWJkb21haW4gUmVwb3J0aW5nDQo+DQo+IEluIGFydGljbGUNCj4gPE1O MlBSMTFNQjQzNTEwRjI3QTcwMEM5NjQ0RjlCQUVENEY3Q0EwQE1OMlBSMTFNQjQzNTEubmFtcHJk DQo+IDExLnByb2Qub3V0bG9vay5jb20+IHlvdSB3cml0ZToNCj4gPkJhc2VkIG9uIGEgZGlzY3Vz c2lvbiBmcm9tIGxhc3QgeWVhcg0KPiA+KGh0dHBzOi8vdXJsZGVmZW5zZS5jb20vdjMvX19odHRw czovL21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gvbXNnL2RtYXINCj4gPmMvWW9IaGhhQWZ3Umpi ZDhhcTRmaVY2eFUxaWZ3L19fOyEhQ1FsM21jSFgyQSFXZUoyazBOV0g1bU1IM3haNA0KPiBtNTBx Z2FuNExLWC0xZEprRzlFSWJPcEFRU2hxOUIxbVFQN3V3RkxCeUNhRUNCUTdZcG8kICksIHRoZXJl IHdhcw0KPiBhIHJlcXVlc3QvdGlja2V0IHRvIGNsYXJpZnkgdGhlIGxhbmd1YWdlIGluIHRoZSBk b2N1bWVudC4NCj4gPg0KPiA+PkZyb20NCj4gaHR0cHM6Ly91cmxkZWZlbnNlLmNvbS92My9fX2h0 dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM3NDg5KnNlY3Rpb24tDQo+IDcuMl9fO0l3ISFD UWwzbWNIWDJBIVdlSjJrME5XSDVtTUgzeFo0bTUwcWdhbjRMS1gtDQo+IDFkSmtHOUVJYk9wQVFT aHE5QjFtUVA3dXdGTEJ5Q2FFRXJNVXdxZyQgOg0KPiA+DQo+ID4gKiAgRGF0YSBmb3IgZWFjaCBE b21haW4gT3duZXIncyBzdWJkb21haW4gc2VwYXJhdGVseSBmcm9tIG1haWwgZnJvbQ0KPiA+ICAg ICAgdGhlIHNlbmRlcidzIE9yZ2FuaXphdGlvbmFsIERvbWFpbiwgZXZlbiBpZiB0aGVyZSBpcyBu byBleHBsaWNpdA0KPiA+ICAgICAgc3ViZG9tYWluIHBvbGljeQ0KPg0KPiBUaGF0IHdvdWxkIGJl IGEgY2hhbmdlIHRvIHRoZSBYTUwgcmVwb3J0IHNjaGVtYS4gSXQnZCBjaGFuZ2UgYXMgSSBzaG93 IGJlbG93DQo+IHRvIGZvcmNlIGEgc2VwYXJhdGUgcm93IGZvciBlYWNoIGhlYWRlcl9mcm9tLg0K Pg0KPiBUaGF0J3MgYSBzb21ld2hhdCBpbmNvbXBhdGlibGUgY2hhbmdlLCBzbyBJJ2Qgd2FudCB0 byBiZSBzdXJlIHdlIGFncmVlIHRoYXQNCj4gaXQncyBhIHJlYWwgcHJvYmxlbSB0aGF0J3Mgd29y dGggY2hhbmdpbmcgdGhlIHJlcG9ydCBmb3JtYXQuIEkgc3VwcG9zZSBpZiB3ZSBkbw0KPiB3ZSBz aG91bGQgZW5jb3VyYWdlIHJlcG9ydCBjb25zdW1lcnMgdG8gYmUgcHJlcGFyZWQgZm9yIG9sZCBh bmQgbmV3IGZvcm1hdHMuDQoNClRoZSBnb2FsIHdhcyB0byBjbGFyaWZ5IHRoZSBsYW5ndWFnZSwg d2l0aG91dCAodG8gdGhlIGJlc3Qgb2Ygb3VyIGFiaWxpdHkpIGNoYW5naW5nIHRoZSBzY2hlbWEu ICBJJ2Qgd2VsY29tZSBhIG90aGVyIGF0dGVtcHRzIGF0IGNsYXJpZmljYXRpb25zIChpZiB5b3Ug YmVsaWV2ZSBtaW5lIGludHJvZHVjZXMgc3RydWN0dXJhbCBYTUwgY2hhbmdlcykuDQoNCg0KPg0K PiBSJ3MsDQo+IEpvaG4NCj4NCj4NCj4gICAgPHhzOmNvbXBsZXhUeXBlIG5hbWU9IklkZW50aWZp ZXJUeXBlIj4NCj4gICAgICA8eHM6YWxsPg0KPiAgICAgICAgPCEtLSBUaGUgZW52ZWxvcGUgcmVj aXBpZW50IGRvbWFpbi4gLS0+DQo+ICAgICAgICA8eHM6ZWxlbWVudCBuYW1lPSJlbnZlbG9wZV90 byIgdHlwZT0ieHM6c3RyaW5nIg0KPiAgICAgICAgICAgICAgICAgICAgbWluT2NjdXJzPSIwIi8+ DQo+ICAgICAgICA8IS0tIFRoZSBSRkM1MzIxLk1haWxGcm9tIGRvbWFpbi4gLS0+DQo+ICAgICAg ICA8eHM6ZWxlbWVudCBuYW1lPSJlbnZlbG9wZV9mcm9tIiB0eXBlPSJ4czpzdHJpbmciDQo+ICAg ICAgICAgICAgICAgICAgICBtaW5PY2N1cnM9IjEiLz4NCj4gT2xkOg0KPiAgICAgICAgPCEtLSBU aGUgUkZDNTMyMi5Gcm9tIGRvbWFpbi4gLS0+DQo+ICAgICAgICA8eHM6ZWxlbWVudCBuYW1lPSJo ZWFkZXJfZnJvbSIgdHlwZT0ieHM6c3RyaW5nIg0KPiAgICAgICAgICAgICAgICAgICAgbWluT2Nj dXJzPSIxIi8+DQo+DQo+IE5ldzoNCj4gICAgICAgIDwhLS0gVGhlIFJGQzUzMjIuRnJvbSBkb21h aW4uIC0tPg0KPiAgICAgICAgPHhzOmVsZW1lbnQgbmFtZT0iaGVhZGVyX2Zyb20iIHR5cGU9Inhz OnN0cmluZyIvPg0KPg0KPiAgICAgIDwveHM6YWxsPg0KPiAgICA8L3hzOmNvbXBsZXhUeXBlPg0K From nobody Fri Dec 11 13:34: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 DBBFF3A0F00 for ; Fri, 11 Dec 2020 13:34:25 -0800 (PST) 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 (2048-bit key) header.d=iecc.com header.b=jOs0h4gt; dkim=pass (2048-bit key) header.d=taugh.com header.b=m/vojBqn Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aCAIItaieOXF for ; Fri, 11 Dec 2020 13:34:24 -0800 (PST) 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 0101B3A0EFF for ; Fri, 11 Dec 2020 13:34:23 -0800 (PST) Received: (qmail 81149 invoked from network); 11 Dec 2020 21:34:21 -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=13cfb.5fd3e5dd.k2012; i=johnl-iecc.com@submit.iecc.com; bh=2GFRJBtFd631VXA+AH1RiOv/PfQ5gMuoD7ObsJ44ye0=; b=jOs0h4gtLsPOw8l4qLOYiaqAGz9qao63fc9bFeWtBPV3rmuZeMi47S2kYFlxUqzyn0vmy8Ba0+E7qmkOd9xgWsSXFSl+ZuVTeFuwDA8yu3tdihaKR6e1/E5VPYrrBhKrbrYpz+bTxCZM33Il/Vn4+BYlwx2juwBaqTOnFA3CgUrOfalzHzpwVz8wt/cYWNyA74CUIKv0wtqsHO4OJj6UTTjUvpgvI4zJTighnrpLDAQ0N9jDTzVPIF5OeigDXX7/rv4zuUS7EIVDbW+FVIJkwgO4zknzH8nCpLo5c/B0prkUxJ6BBF0tnPC1Ts1RivHN4G18kT0h1hxhgxuisIwyEw== 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=13cfb.5fd3e5dd.k2012; olt=johnl-iecc.com@submit.iecc.com; bh=2GFRJBtFd631VXA+AH1RiOv/PfQ5gMuoD7ObsJ44ye0=; b=m/vojBqnQSsTlONsUZKRVTVhFMe9U2f0t9oI7dEXhrIXCTgba45wVxXBXvHwTlGCAIKKHLGfXD0pLK8QTNd6pGJeiEQsKqVHoq7QLFzVSSdTyywyBm1p0cwjkmctRc56CCe1g6ct7VTc7iXezQIUQ+gKXW+BByLsCg4VcLzzAD3pyGITJXvuN9zsHkGLMHANizGhC4kSy3bnyb4QX1I4bHNEwvELE22T7owFVeXFUwvfQWNWeKHck0BpLdANtZMdOSJKdVolFolzQLuStiGTFQV5Bkl8BOtv+5v7G/7OwMfJ7mzWZnIU0kz1xKrHTs67T41lDLImCs0Ih5a7LhSHIA== 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; 11 Dec 2020 21:34:21 -0000 Date: 11 Dec 2020 16:34:20 -0500 Message-ID: From: "John R Levine" To: "Brotman, Alex" , "dmarc@ietf.org" In-Reply-To: References: <20201211193845.63466297AE5D@ary.qy> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [dmarc-ietf] [EXTERNAL] Re: Clarification of Subdomain Reporting X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 11 Dec 2020 21:34:26 -0000 On Fri, 11 Dec 2020, Brotman, Alex wrote: >> That's a somewhat incompatible change, so I'd want to be sure we agree that >> it's a real problem that's worth changing the report format. I suppose if we do >> we should encourage report consumers to be prepared for old and new formats. > > The goal was to clarify the language, without (to the best of our ability) changing the schema. I'd welcome a other attempts at clarifications (if you believe mine introduces structural XML changes). So it'd say yeah, we know the XML lets you put multiple header_from domains in the same report row, but please don't do that, send a separate report row for each header_from? I suppose that could work. R's, John >> >> >> >> > minOccurs="0"/> >> >> > minOccurs="1"/> >> Old: >> >> > minOccurs="1"/> >> >> New: >> >> >> >> >> > 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 Dec 11 18:14: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 8C0383A0D3A for ; Fri, 11 Dec 2020 18:14:15 -0800 (PST) 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=N56BJfUE; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=QDp8XkJU Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ko9whEWHcb_S for ; Fri, 11 Dec 2020 18:14:13 -0800 (PST) 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 60A733A0D39 for ; Fri, 11 Dec 2020 18:14:12 -0800 (PST) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1200; t=1607739243; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=04ZnJGX+AOlRCKGKovLuKoY3PRp3 QZN4NfjxtbemXwU=; b=N56BJfUEk6UDjhZfUunGEsKiwdjXdskfb1WqYXL33SLq vwjyEJVIhYPOnhAAx7LyWwDH7/HCxA63mxDFxIOCIGZesymBN0HuRqC26V6hAqgZ 6K2fakGkAo6hqodUxfZ5ngV0UHFpWdm32RE29XtkwltpXkmXbrMTVYnzYjYWPN0= Received: by mail.winserver.com (Wildcat! SMTP Router v8.0.454.10) for dmarc@ietf.org; Fri, 11 Dec 2020 21:14:03 -0500 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 1179324942.6153.2468; Fri, 11 Dec 2020 21:14:02 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1200; t=1607738900; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=04ZnJGX +AOlRCKGKovLuKoY3PRp3QZN4NfjxtbemXwU=; b=QDp8XkJUnljxbC8hCCKw9t5 Cl23VdfHiiubL+O5+wc3kUAavT8VseimMWCia0PvVabBJhWI2g3jQCKhwiFeAMdy cVMBoDjx6oVMOsVTrwJS+52UGBfzhQmkWaTpc0mWnBhMgIlEyn9gjXlpM6FDmzlT 8JnEHptyiYpBugCDUsts= Received: by beta.winserver.com (Wildcat! SMTP Router v8.0.454.10) for dmarc@ietf.org; Fri, 11 Dec 2020 21:08:20 -0500 Received: from [192.168.1.68] ([75.26.216.248]) by beta.winserver.com (Wildcat! SMTP v8.0.454.10) with ESMTP id 1046204626.1.8332; Fri, 11 Dec 2020 21:08:19 -0500 Message-ID: <5FD4276E.6080101@isdg.net> Date: Fri, 11 Dec 2020 21:14:06 -0500 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: Dotzero CC: Dave Crocker , IETF DMARC WG , "Kurt Andersen (b)" References: <923de33f-3707-facf-389e-371f6ee64008@gmail.com> <16B0B820-7080-4937-8642-3A6B84B441AA@gmail.com> <1f5b3e62-e6f4-0bc2-221e-362667536727@gmail.com> <8e0ff141-2842-606c-91e9-e588edab7ef1@gmail.com> <5FD39A0E.5000300@isdg.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] p=quarantine X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 12 Dec 2020 02:14:16 -0000 On 12/11/2020 11:19 AM, Dotzero wrote:> > > On Fri, Dec 11, 2020 at 11:11 AM Hector Santos > >> We are not doing reporting at this time. Not the main focus. >> That can come later as an augmented feature, in fact, we might >> consider it as a paid service to be sending thousands report out >> to domains. > > That's good community spirit. eh, thanks? > I doubt many would be willing to pay you for your reports. Customers are already paying for the total platform (not open source, not free, its expensive commercial hosting software). It comes without any DMARC reporting except with the description to add DMARC report tags to collect the reports and instructions to redirect the notifications to specific admin-only mail areas. No Doubt, this is an easy added-value feature when we are ready to offer the ad-hoc reporting capability added to their existing Wildcat! Ad-hoc Reporting tools (an paid for add-on). How do you benefit from DMARC? What is your rejection (or protect domain action) average? Do you allow subscriptions to your mailing list services or you do rewriting? -- Hector Santos, https://secure.santronics.com https://twitter.com/hectorsantos From nobody Sat Dec 12 02:36: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 652063A0FF0 for ; Sat, 12 Dec 2020 02:36:46 -0800 (PST) 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 s1xPhUdkrrW4 for ; Sat, 12 Dec 2020 02:36:44 -0800 (PST) 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 B40EB3A0FEB for ; Sat, 12 Dec 2020 02:36:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1607769401; bh=U7sV9omDEuZS2ROYzYspNi8qiTad2SRuGZalYXrNc9Q=; l=2657; h=To:References:From:Date:In-Reply-To; b=C4GixwPxejWe74dp6hNZxDGtYl1TQWO5YQuLNGcfZEEZ/Yeas/TisV7+oNP48ER9J adF6EcHyM/lgO96RR/PsJJ7kHxGED8AkmB87fg2Zhz6or6y+RkU5wGxILOajdoou+J 9u0KdyHe/aybnVFR3lOOYnUTj/Ud4FkOixJEEX889aGJTbR+Zu0iALHHW+rKT Authentication-Results: tana.it; auth=pass (details omitted) Original-From: Alessandro Vesely 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.000000005FD49D39.00003732; Sat, 12 Dec 2020 11:36:41 +0100 To: Jesse Thompson , dmarc@ietf.org References: <609e1c9b-cc4d-d7d1-0fa8-79f515c1eee4@tana.it> <20201209185246.1D40C29474C4@ary.qy> <747eae71-24e7-fd05-2123-2c22ae4588e8@tana.it> <20575bf1-3813-4b3c-e59c-54e38b0da670@wisc.edu> From: Alessandro Vesely Message-ID: <5b54d4e3-6bec-2e88-1071-befe236c9812@tana.it> Date: Sat, 12 Dec 2020 11:36:41 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: <20575bf1-3813-4b3c-e59c-54e38b0da670@wisc.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Ticket #61 - Define and add a simplified (redacted) failure report X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 12 Dec 2020 10:36:46 -0000 On Fri 11/Dec/2020 18:24:16 +0100 Jesse Thompson wrote: > On 12/11/20 7:48 AM, Alessandro Vesely wrote: >> On Thu 10/Dec/2020 17:59:54 +0100 Jesse Thompson wrote: >>> On 12/9/20 10:28 PM, seth wrote: >>>> As an individual, I feel extremely strongly that failure reports should go away in their entirety. Although Jesse Thompson has outlined a use case that really has no other good solution, and is equally true in other large complicated organizations. >>> >>> To be clear, I'm not advocating for this From/To use case, but I know of universities who would. There's at least one who cleverly flattened their SPF record to include every known sender specifically because they had no mission to change the way their institution distributively sends email. That is the type of organization who *may* want From/To data, assuming they want to do more validation before adding yet another IP to their SPF. It's a stretch in my mind. >> >> I'm not clear whether you're talking about sending or receiving reports. Received: chains are key for evaluating addresses to add to SPF records. I don't think it makes sense to specify their omission from > > Only the last hop from the receiver's viewpoint is really needed for a domain owner to assess gaps in SPF. That's already addressed with aggregate reports. What's missing is the additional context that the failure reports are intended to provide, to help domain owners determine if the IP address which sent the message was legitimate. Of course, received chains are helpful for troubleshooting. There's no "right" answer regarding the balance of useful information vs privacy, so I'm suggesting that we put things like this on a spectrum of usefulness/privacy-concerning. Thus far, the spec doesn't discuss what to redact, except for mentioning local parts of email addresses. >> My guess at why an organization may want to send only From/To rather than a possibly redacted text/rfc822-headers are as follows: >> >> * It is too hard for them to asses the risk of including unknown header fields, yet they must do it before enabling ruf, >> >> * the software they use doesn't have an option to redact PII, or (unlikely) >> >> * they try to save bandwidth and disk space by reducing that ghastly pile of freaky fields that infest message headers these days. > > If sending only a limited amount of information is considered an acceptable alternative to full/unredacted information, it might help encourage these organizations to send failure reports, perhaps? I'm surprised that the request in this ticket proposes to send only the two most sensitive fields. Best Ale -- From nobody Sat Dec 12 02:52: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 6B63A3A1010 for ; Sat, 12 Dec 2020 02:52:33 -0800 (PST) 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 7PEhUQFdIw67 for ; Sat, 12 Dec 2020 02:52:31 -0800 (PST) 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 A942C3A100D for ; Sat, 12 Dec 2020 02:52:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1607770348; bh=OsxWL3g8fWL33c+nuK0/uALMXF4H8LIx4v0FbeAewOI=; l=1854; h=To:References:From:Date:In-Reply-To; b=AO7lpXYqu3exZLZ0UnrKWqSdmbkkJ4nqDyIsieVGocaRhGyjXFlVeGXSD/5AiFMRg YLuxEeZO4PKuwlCFuIEh05jn9nCGTtHxsKPmjNVP+uK2jXUqRIctboj2eMNnNTV3B9 VHVo3PZ7WyFAL2Q44Y87n2eafbeYn6V8RyboBVKdgZpqmhqZ0dedHq2tu36aZ Authentication-Results: tana.it; auth=pass (details omitted) Original-From: Alessandro Vesely 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 00000000005DC0C0.000000005FD4A0EC.00003938; Sat, 12 Dec 2020 11:52:28 +0100 To: dmarc@ietf.org References: <20201211193845.63466297AE5D@ary.qy> From: Alessandro Vesely Message-ID: <6c5878e8-fdd8-05c0-3b60-ba180ecbc391@tana.it> Date: Sat, 12 Dec 2020 11:52:28 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: <20201211193845.63466297AE5D@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] Clarification of Subdomain Reporting X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 12 Dec 2020 10:52:33 -0000 On Fri 11/Dec/2020 20:38:44 +0100 John Levine wrote: > In article you write: >>Based on a discussion from last year >>(https://mailarchive.ietf.org/arch/msg/dmarc/YoHhhaAfwRjbd8aq4fiV6xU1ifw/), there was a >>request/ticket to clarify the language in the document. >> >>>From https://tools.ietf.org/html/rfc7489#section-7.2: >> >> * Data for each Domain Owner's subdomain separately from mail from >> the sender's Organizational Domain, even if there is no explicit >> subdomain policy > > That would be a change to the XML report schema. It'd change as I show > below to force a separate row for each header_from. Maybe it's me, but I don't understand the change below. The only difference I see between Old: and New: is the removal of «minOccurs="1"». Since that is the default value, I see no incompatibility. What am I missing? BTW, I passionately hope we're going to change the schema anyway (selector, version, ...) Best Ale > That's a somewhat incompatible change, so I'd want to be sure we agree > that it's a real problem that's worth changing the report format. I > suppose if we do we should encourage report consumers to be prepared > for old and new formats. > > R's, > John > > > > > > minOccurs="0"/> > > minOccurs="1"/> > Old: > > minOccurs="1"/> > > New: > > > > > > From nobody Sat Dec 12 06:45: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 DD6643A1155 for ; Sat, 12 Dec 2020 06:45:38 -0800 (PST) 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 WVNQmGAyFTo5 for ; Sat, 12 Dec 2020 06:45:36 -0800 (PST) Received: from mail-pg1-x530.google.com (mail-pg1-x530.google.com [IPv6:2607:f8b0:4864:20::530]) (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 724E13A114C for ; Sat, 12 Dec 2020 06:45:36 -0800 (PST) Received: by mail-pg1-x530.google.com with SMTP id w16so9322243pga.9 for ; Sat, 12 Dec 2020 06:45:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:to:references:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=h0uLmyN8/axom3+1FrMD2o/3ocugb5RUS8kgAf4hsxU=; b=OwBBKkia/mysoqqHVtF+Gc4EzPbjc66NAcw9I2wxst8jCgyXzg0X0mqets4CT4CuvT t++d/P8FDAVOowmqTUx1H8IKGmcD+nTfGo4jOQj4bn2Y5Ct5x40U6FxSFI2Hxt9/YWaz cPtZdNkKcu5BCahgAXoZA12XTbAnDfYGIeUcfjR5XcQBeWqqF/vZTmyt4WdFHcFie1lr ZL60RST/wLkoZ/CxR37qHKoS9tX9sxxSfeUZlLJ/D1j6gauLsgFN4fZYoJ8dNN45Za1U acpA0Rp1C0dUVP3dDaWCZ4eTO6mR/fWyhTucUIcf4WNNqwAKU3Sqj0LMbeaNXw4oPfFv AWhw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:references:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=h0uLmyN8/axom3+1FrMD2o/3ocugb5RUS8kgAf4hsxU=; b=YZ6Z1Ql2KODFp3vVykTJ8zt++LLcChcSi3x3uwc9FczsVPsT+Sg/UuVeP3yFV4umg0 IemE/roSEsnmZh8q18BAXrBj3jM7MvEVkHZhtb3aO+XctCMcq5bpvxk78pNGJEHe5hrk s51PFS9oPd6gHqVd92upX2pjbgpFZJmMrmqOe9hKQ1xYQEqCO9mXIvj6TP8BtYi9gCkT c6yOvoa0dfXI/hQRf6I1eVaUv0PM4inBodx4B+JBIi95oH+chRIApF5kmGyB4TPdsE5D 7vc6MiUmBWcGm7Ft4q3JldccA3w6vQiwKrumKJu829gNS0Fh3+BZxlvoN8MHjg0ncNgA YRyQ== X-Gm-Message-State: AOAM532wVBgvmt963khNbk7cWsydzopQdDrF3ucoBymebVDEaflArpdW SWOdZWRwelFPVgECMwx5wTIEV56tu6w= X-Google-Smtp-Source: ABdhPJwTrnIDmNN3AZ5CXQn2JJTjuzbPpoUVQYsCeYG6x0OYzCL1fw66M2Lb5yc4AWfmEBzjEgxIqw== X-Received: by 2002:aa7:8b15:0:b029:196:59ad:ab93 with SMTP id f21-20020aa78b150000b029019659adab93mr16050668pfd.16.1607784335497; Sat, 12 Dec 2020 06:45:35 -0800 (PST) Received: from [192.168.0.109] (c-24-130-62-181.hsd1.ca.comcast.net. [24.130.62.181]) by smtp.gmail.com with ESMTPSA id h17sm13581464pfo.220.2020.12.12.06.45.34 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 12 Dec 2020 06:45:34 -0800 (PST) From: Dave Crocker To: Todd Herr , IETF DMARC WG References: <160513169495.16356.6565556939968267867@ietfa.amsl.com> Message-ID: <3a5548b7-cb41-1533-93c3-dbecc800be19@gmail.com> Date: Sat, 12 Dec 2020 06:45:31 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------FBC624D15EE5ED74A86A8B1A" Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] Proposed Introduction and Abstract (was I-D Action: draft-ietf-dmarc-dmarcbis-00.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: Sat, 12 Dec 2020 14:45:39 -0000 This is a multi-part message in MIME format. --------------FBC624D15EE5ED74A86A8B1A Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Some comments and suggestions... On 11/19/2020 2:55 PM, Todd Herr wrote: > This thread hasn't generated any discussion or momentum yet, and I > know that's not because y'all have found the proposed text for the > Abstract and Introduction to be acceptable, so I'm going to add the > text to this thread and see where the discussion leads. > > ----------------------------------------------- cut here > ---------------------------------------------------- > > Abstract > > > This document describes the Domain-based Message Authentication, > > Reporting, and Conformance (DMARC) protocol. > > > DMARC is a scalable mechanism by which a mail-originating > > organization can express domain-level policies and preferences for > > message validation, disposition, and reporting.Mail-receiving > > organizations can in turn use these expressions of policies and > > preferences to inform their mail handling decisions should they > > choose to do so. > Alternative second par, to improve focus and provide  more complete, initial description: DMARC permits the owner of an author's domain name to enable validation of the domain's use, to indicate the implication of failed validation, and to request reports about use of the domain name. Mail receiving organizations can use this information when evaluating disposition choices for incoming mail. I suggest this introductory text focus less on low-level technical details or references, and more on setting the stage, by characterizing functional benefits and, perhaps, very general statements about the approach.  This is the place to build market demand, by focusing on the why and what, not the how. > This document obsoletes RFC 7489. > > > [...] > > > > 1.Introduction > > > RFC EDITOR: PLEASE REMOVE THE FOLLOWING PARAGRAPH BEFORE PUBLISHING: > > The source for this draft is maintained in GitHub at: > > https://github.com/ietf-wg-dmarc/draft-ietf-dmarc-dmarcbis > > > (https://github.com/ietf-wg-dmarc/draft-ietf-dmarc-dmarcbis > ) > > > The Sender Policy Framework ([RFC7208]) and DomainKeys Identified > > Mail ([RFC6376]) protocols provide domain-level authentication, and > ...authentication, which is not directly associated to the rfc5322.From field domain name, and DMARC... > DMARC builds on these protocols.DMARC is designed to give > > ADminstrative Management Domains (ADMDs) that originate email > theability to publish in a DNS TXT record their email authentication > > policies, specify preferred handling for mail that fails > > authentication checks, and request reports about mail purportedly > > originated by the ADMD, as determined by the RFC5322.From header in > > the message. > Repeating from the Abstract: DMARC Builds on these protocols. DMARC permits the owner of an author's domain name to enable validation of the domain's use, to indicate the implication of failed validation, and to request reports about use of the domain name. Mail receiving organizations can use this information when evaluating disposition choices for incoming mail. The 'domain' in ADMD is not the same as in 'domain name' and, arguably, DMARC has nothing to do with ADMDs, but only with domain names.  This is an important distinction.  The linkage between the two comes from operational arrangement, not anything inherent in DMARC.  I'm not sure how to reflect this fact in the text. /d btw, use of vocabulary like ADMD changes the requirement for the reference to RFC 5598, in the Terminology section.  The current text is a casual suggestion.  It needs to be something like: References and terminology that are not defined in this specification are drawn from RFC 5598. > > As with SPF and DKIM, DMARC authentication checks result in verdicts > > of "pass" or "fail".A DMARC pass verdict requires not only that SPF > > or DKIM pass for the message in question, but also that the domain > > validated by the SPF or DKIM check is aligned with the domain in the > > RFC5322.From header.In the DMARC protocol, two domains are said to > perhaps add reference to Section 3.1, for definition of alignment, rather than do a definition here.  Having something defined more than once in a specification can get problematic. > be "in alignment" if they have the same Organizational Domain > > (a.k.a., relaxed alignment) or they are identical (a.k.a., strict > > alignment). > > > A DMARC pass verdict asserts only that the RFC5322.From domain has > verdict -> resut asserts -> indicates > been authenticated in that message; there is no explicit or implied > > value assertion attributed to a message that receives such a verdict. > > A mail-receiving organization that performs DMARC validation checks > > on inbound mail can choose to use the results and the preferences > > expressed by the originating domain for message disposition to inform > > its mail handling decision for that message.For messages that pass > A mail-receiving organization that performs a DMARC validation check on inbound mail can choose to use the result and the published assessment by the originating domain for message disposition to inform its mail handling decision for that message. trying to move away from policy or directive (also changed to singular; it seems to make specification language easier to write...) > DMARC validation checks, the mail-receiving organization can be > > confident in applying handling based on its known history for > > similarly authenticated messages, whereas messages that fail such > > checks cannot be reliably associated with a domain with a history of > > sending DMARC-validated messages. > For mail-receiving organization supporting DMARC, a message that pass validation is part of a message stream that is reliably associated with the domain owner.  Therefore reputation assessment of that stream, by the mail-receiving organization, does not need to be encumbered by  accounting for unauthorized use of the domain. A message that fails this validation cannot reliably be associated with the aligned domain and its reputation. > > DMARC also describes a reporting framework in which mail-receiving > > domains can generate regular reports containing data about messages > > seen that claim to be from domains that publish DMARC policies, and > > send those reports to the ADMD as requested by its DMARC policy > > record. > ADMD -> address While another use of ADMD is appealing, the construct in this part of DMARC is really just an address.  Any address. > > Experience with DMARC has revealed some issues of interoperability > > with email in general that require due consideration before > > deployment, particularly with configurations that can cause mail to > > be rejected.These are discussed in Section 9. > > > d/ -- Dave Crocker dcrocker@gmail.com 408.329.0791 Volunteer, Silicon Valley Chapter American Red Cross dave.crocker2@redcross.org --------------FBC624D15EE5ED74A86A8B1A Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Some comments and suggestions...


On 11/19/2020 2:55 PM, Todd Herr wrote:
This thread hasn't generated any discussion or momentum yet, and I know that's not because y'all have found the proposed text for the Abstract and Introduction to be acceptable, so I'm going to add the text to this thread and see where the discussion leads.

----------------------------------------------- cut here ----------------------------------------------------

Abstract


   This document describes the Domain-based Message Authentication,

   Reporting, and Conformance (DMARC) protocol.


   DMARC is a scalable mechanism by which a mail-originating

   organization can express domain-level policies and preferences for

   message validation, disposition, and reporting.  Mail-receiving

   organizations can in turn use these expressions of policies and

   preferences to inform their mail handling decisions should they

   choose to do so.

Alternative second par, to improve focus and provide  more complete, initial description:

DMARC permits the owner of an author's domain name to enable validation of the domain's use, to indicate the implication of failed validation, and to request reports about use of the domain name. Mail receiving organizations can use this information when evaluating disposition choices for incoming mail.

I suggest this introductory text focus less on low-level technical details or references, and more on setting the stage, by characterizing functional benefits and, perhaps, very general statements about the approach.  This is the place to build market demand, by focusing on the why and what, not the how.


   This document obsoletes RFC 7489.


[...]



1.  Introduction


   RFC EDITOR: PLEASE REMOVE THE FOLLOWING PARAGRAPH BEFORE PUBLISHING:

   The source for this draft is maintained in GitHub at:

   https://github.com/ietf-wg-dmarc/draft-ietf-dmarc-dmarcbis

   (https://github.com/ietf-wg-dmarc/draft-ietf-dmarc-dmarcbis)


   The Sender Policy Framework ([RFC7208]) and DomainKeys Identified

   Mail ([RFC6376]) protocols provide domain-level authentication, and

...authentication, which is not directly associated to the rfc5322.From field domain name, and DMARC...


   DMARC builds on these protocols.  DMARC is designed to give

   ADminstrative Management Domains (ADMDs) that originate email the   ability to publish in a DNS TXT record their email authentication

   policies, specify preferred handling for mail that fails

   authentication checks, and request reports about mail purportedly

   originated by the ADMD, as determined by the RFC5322.From header in

   the message.


Repeating from the Abstract:

DMARC Builds on these protocols. DMARC permits the owner of an author's domain name to enable validation of the domain's use, to indicate the implication of failed validation, and to request reports about use of the domain name. Mail receiving organizations can use this information when evaluating disposition choices for incoming mail.

The 'domain' in ADMD is not the same as in 'domain name' and, arguably, DMARC has nothing to do with ADMDs, but only with domain names.  This is an important distinction.  The linkage between the two comes from operational arrangement, not anything inherent in DMARC.  I'm not sure how to reflect this fact in the text. /d

btw, use of vocabulary like ADMD changes the requirement for the reference to RFC 5598, in the Terminology section.  The current text is a casual suggestion.  It needs to be something like:

References and terminology that are not defined in this specification are drawn from RFC 5598.



   As with SPF and DKIM, DMARC authentication checks result in verdicts

   of "pass" or "fail".  A DMARC pass verdict requires not only that SPF

   or DKIM pass for the message in question, but also that the domain

   validated by the SPF or DKIM check is aligned with the domain in the

   RFC5322.From header.  In the DMARC protocol, two domains are said to

perhaps add reference to Section 3.1, for definition of alignment, rather than do a definition here.  Having something defined more than once in a specification can get problematic.


   be "in alignment" if they have the same Organizational Domain

   (a.k.a., relaxed alignment) or they are identical (a.k.a., strict

   alignment).


   A DMARC pass verdict asserts only that the RFC5322.From domain has

verdict -> resut

asserts -> indicates


   been authenticated in that message; there is no explicit or implied

   value assertion attributed to a message that receives such a verdict.

   A mail-receiving organization that performs DMARC validation checks

   on inbound mail can choose to use the results and the preferences

   expressed by the originating domain for message disposition to inform

   its mail handling decision for that message.  For messages that pass

A mail-receiving organization that performs a DMARC validation check

on inbound mail can choose to use the result and the published assessment

by the originating domain for message disposition to inform

its mail handling decision for that message.

trying to move away from policy or directive

(also changed to singular; it seems to make specification language easier to write...)


   DMARC validation checks, the mail-receiving organization can be

   confident in applying handling based on its known history for

   similarly authenticated messages, whereas messages that fail such

   checks cannot be reliably associated with a domain with a history of

   sending DMARC-validated messages.

For mail-receiving organization supporting DMARC, a message that pass validation is part of a message stream that is reliably associated with the domain owner.  Therefore reputation assessment of that stream, by the mail-receiving organization, does not need to be encumbered by  accounting for unauthorized use of the domain. A message that fails this validation cannot reliably be associated with the aligned domain and its reputation.
 


   DMARC also describes a reporting framework in which mail-receiving

   domains can generate regular reports containing data about messages

   seen that claim to be from domains that publish DMARC policies, and

   send those reports to the ADMD as requested by its DMARC policy

   record.

ADMD -> address

While another use of ADMD is appealing, the construct in this part of DMARC is really just an address.  Any address.



   Experience with DMARC has revealed some issues of interoperability

   with email in general that require due consideration before

   deployment, particularly with configurations that can cause mail to

   be rejected.  These are discussed in Section 9.





d/


-- 
Dave Crocker
dcrocker@gmail.com
408.329.0791

Volunteer, Silicon Valley Chapter
American Red Cross
dave.crocker2@redcross.org
--------------FBC624D15EE5ED74A86A8B1A-- From nobody Sat Dec 12 10:42:30 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DE0C3A127C for ; Sat, 12 Dec 2020 10:42:29 -0800 (PST) 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 EcV-fxHqHYJY for ; Sat, 12 Dec 2020 10:42:28 -0800 (PST) Received: from mail-pg1-x52c.google.com (mail-pg1-x52c.google.com [IPv6:2607:f8b0:4864:20::52c]) (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 47F2D3A0D6F for ; Sat, 12 Dec 2020 10:42:28 -0800 (PST) Received: by mail-pg1-x52c.google.com with SMTP id w16so9578833pga.9 for ; Sat, 12 Dec 2020 10:42:28 -0800 (PST) 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=o0KbBaAMPOdMRyAHm+zAJphsmRYRhCAN0nZhlhTxbrI=; b=VG3X7i4FVMNVj98kdHYe7wLQe+KSLvmsKkyuzGXrF0gKE+UsR4eFUr5agNZsrLkiGp Cxr3YiVBCmLz4cXqIeB+fejnluN+sPp7Pp9zAoDHqxoQZmekCitu/ZDDQ8xG+XSBuiW2 Y6HKqJat1jL8mOlBrxnXyOTVIoXXVBGswVmshREeRd+cc3gvhrcImb96m9k8dyGnGs6l N7ieSRjl2x+oLDq9vR+YlKDFxnlzlu8Qz9znNZpP0MnothxIiFLm7glUCyg55V7pdc4i LGfXQ9Yh0GSw+gmYrJK11xCI59CNp0RgbKkemYyfQwM2gW+m+PpntLyxoIm02wZ9dLsf JjAQ== 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=o0KbBaAMPOdMRyAHm+zAJphsmRYRhCAN0nZhlhTxbrI=; b=UOpZI7j5Vr/Fzy9xuw/NJtg2xpWv6aMe9/N3YcSLAQV93qiaS3pvT7PyJQWli0S15y 51Gq4YQuwQ1xBVKc6lw4TWOSWwKbgAt8cCoA4Njl4UsX/+rXYBkkGxlKKbqekUz/JOEs IxPwiUwkT0R6iww94ZgaTKT/r1pCZIUwdqz6KIBmS61lsRU+x1VQ9MJNFce10D6fFSE2 CXuoNaEzpHuFS1zFL/0uMOceCvEDj1+rZYgNe0EDeSt0ktmuUS07ZTznnY9zFm8QU+lJ JaHcz/fY8j/A/qpiXOTuu8tqVt4IUnh6GtomW2T7KbWQnqi8irK6EIF5XS0vsmrcYMxO 8i/A== X-Gm-Message-State: AOAM532GSEx2zxuZjNw3hWIPScc2bE1l9keAzc1zvus3lOW3fj/+PZrz 7dXrifC520iLPWLMkjAIKFdJnEhRQYQ= X-Google-Smtp-Source: ABdhPJyzsDcwtDWbiE50tWAuVL98wPO0kiDe8gSE3MKEN4RjHrHgZqsnIHxTEHmuLIu+Kj7lBDB3og== X-Received: by 2002:a05:6a00:7c7:b029:19d:bab0:bc90 with SMTP id n7-20020a056a0007c7b029019dbab0bc90mr17190569pfu.62.1607798547588; Sat, 12 Dec 2020 10:42:27 -0800 (PST) Received: from [192.168.0.109] (c-24-130-62-181.hsd1.ca.comcast.net. [24.130.62.181]) by smtp.gmail.com with ESMTPSA id js9sm15390220pjb.2.2020.12.12.10.42.26 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 12 Dec 2020 10:42:26 -0800 (PST) To: John Levine , dmarc@ietf.org Cc: laura@wordtothewise.com References: <20201211173722.6B4DF29782C7@ary.qy> From: Dave Crocker Message-ID: Date: Sat, 12 Dec 2020 10:42:25 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.5.1 MIME-Version: 1.0 In-Reply-To: <20201211173722.6B4DF29782C7@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] p=quarantine X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 12 Dec 2020 18:42:30 -0000 On 12/11/2020 9:37 AM, John Levine wrote: > In article <1AC986FF-507B-4917-9C6D-D84E9337FC7A@wordtothewise.com> you write: > aligned is not authorized by the domain owner and may be discarded or rejected by the recipient. > Naah. > > p=reject: all mail sent from this domain should be aligned in a DMARC > compliant way. We believe that unaligned mail is from unauthorized > senders so we ask receivers to reject it, even though that might mean > some of our authorized senders' mail is rejected too. As soon as this specification text, here, contains language about how this information is to be used, should be used, or could be used, it crosses over into creating confusion about expectations of receiver handling. It encourages misguided language such as the receiver 'overriding' sender policy.  The sender has no policies about receiver behavior, because there is no relationship between them. Using milder language here doesn't help, because readers typically do not read like legal or technical scholars. DMARC provides information, not direction. The spec already contains misguided perspective by talking about 'policy' records and, even worse, "policy enforcement considerations". If the document must contain language about receiver choices in message disposition, move it to an overtly non-normative discussion section that legitimately covers a wide range of things that receivers do or don't do (cast as things they might or might not do.)  And make sure none of the language hints at sender 'policy', overrides, or the like. d/ -- Dave Crocker dcrocker@gmail.com 408.329.0791 Volunteer, Silicon Valley Chapter American Red Cross dave.crocker2@redcross.org From nobody Sat Dec 12 10:52: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 72C143A0DBC for ; Sat, 12 Dec 2020 10:52:01 -0800 (PST) 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 (2048-bit key) header.d=iecc.com header.b=VIymoZAR; dkim=pass (2048-bit key) header.d=taugh.com header.b=L7TTnufm Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jMQ3AXh1kktw for ; Sat, 12 Dec 2020 10:51:59 -0800 (PST) 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 916853A0DBA for ; Sat, 12 Dec 2020 10:51:59 -0800 (PST) Received: (qmail 95631 invoked from network); 12 Dec 2020 18:51:55 -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=1758d.5fd5114b.k2012; i=johnl-iecc.com@submit.iecc.com; bh=sIc6U+IP9NYHK2cJozRhgs2Ep1q9gu1Nx+ePVrPAvg0=; b=VIymoZARpuXz/TbRTeO7/dLYCk1hRjobEXhbRsIZganNtZrUlVbir8DevHwNiYgtUeWWZeck/jozdtY7xLcDqMB9kPTRkTdejbRcAUPCQQjAZ/aOHf3IweBe+p0//RfDDxvdx8893S3wggrSBidyxmPVmFiBxYJQUkE8Rb6NEQx/ZtS0Tr2lmktzaJaY9fpsSbFmJrBe5+cIQY5KYTy3fDX0b+Gp7K8wh1xkoxiG9Qiap0cXcvvxELB820OaYo2YPUV5AGnbHmKr+z2JbAck1Wh25M+08VwqbqWor9fLUFzziWN0aUDZ5jKrUC+iupoBi1VIoz82EdGhdQpwJFqVBg== 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=1758d.5fd5114b.k2012; olt=johnl-iecc.com@submit.iecc.com; bh=sIc6U+IP9NYHK2cJozRhgs2Ep1q9gu1Nx+ePVrPAvg0=; b=L7TTnufmInP1jY9c0PDIa9HmhBTjzdUMot+tJUx/VITXdck5w5mwDEoo6Qw6TwT3QB3ku/ZnNUdn3U0YUNsVHb9KnclzEox92Wx3F9C3NmBDmoVHi8ENl+mbsIX53kv59dvQW/70eROEyx/sfjFKp7mPmJqOD3Q1e4q9bpET2bP3lOrqb2p3a1Gb+7t7H75TLg83Ncqqh8tENKsEBY3nv2vKD/EnQd7lM6TUSPx9qWzgUFigB3hxRHJ4zEU6zJ49dkyoUra2TzVuRXl4HRIaSXC4XnBAt1ynabXfTdiqiB36n8zcQuZxFRoNJr75iwHRrjl6KE6KZdiFGkiewvDNfg== 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; 12 Dec 2020 18:51:54 -0000 Date: 12 Dec 2020 13:51:54 -0500 Message-ID: <6dc2d62e-e288-8d8f-44b2-6f42e7e580@taugh.com> From: "John R Levine" To: "Dave Crocker" , dmarc@ietf.org In-Reply-To: References: <20201211173722.6B4DF29782C7@ary.qy> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [dmarc-ietf] p=quarantine X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 12 Dec 2020 18:52:01 -0000 On Sat, 12 Dec 2020, Dave Crocker wrote: >> p=reject: all mail sent from this domain should be aligned in a DMARC >> compliant way. We believe that unaligned mail is from unauthorized >> senders so we ask receivers to reject it, even though that might mean >> some of our authorized senders' mail is rejected too. > > As soon as this specification text, here, contains language about how this > information is to be used, should be used, or could be used, it crosses over > into creating confusion about expectations of receiver handling. I agree with you, which is why I said "believe" and "request". If we're going to have any description of p=none at all it needs to emphasize the point that it's telling you that they consider the messages unusually unimportant. This appears to be at odds with what some DMARC users believe. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From nobody Sat Dec 12 10:57: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 5A24C3A12A5 for ; Sat, 12 Dec 2020 10:57:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.851 X-Spam-Level: X-Spam-Status: No, score=-1.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iecc.com header.b=l8ClChwE; dkim=pass (2048-bit key) header.d=taugh.com header.b=PCfzbYx0 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HWpu6kOsIcvH for ; Sat, 12 Dec 2020 10:57:01 -0800 (PST) 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 CF3983A12A3 for ; Sat, 12 Dec 2020 10:57:00 -0800 (PST) Received: (qmail 96881 invoked from network); 12 Dec 2020 18:56:59 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=17a6f.5fd5127b.k2012; bh=A3wqNuy1/uev1i/k+dkmZnuigP91sWyDRE7NfE1IjFE=; b=l8ClChwEz66fmOdjZJQaGDPDRqpvOdU0Nz8/bYeKKHZgIICvYSaWjyvFHLIySanWeZnF4orbZphTSLmm+OOZUio96bvydz7FVMdFOoTbtVeOZjnEd6m4Y53QJoMlhcSXfCdS4eb5HDuJyyEir3eMM1u6Rw6vEHybk7tneTKKWcO0/m8fHmnZ7Au2Htgm75ea90eY3/e+mitdkOwpDNRsjX4kMbVm+UEh32+sRngl1hdM7AJWHyb1y4ZQRG2vd9JG2p29xzz2YPqcuYR3Yw7WMxL1A5IMVBFJtHpko8XhLRYILlfp7V57sKuHMo5jLt/5YTDBkQ+PfX9yxOGVcH9GbA== DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=17a6f.5fd5127b.k2012; bh=A3wqNuy1/uev1i/k+dkmZnuigP91sWyDRE7NfE1IjFE=; b=PCfzbYx07bqkXLqZ3z88ErOhIHCQgR1HQQS95/Y2qKke4Mi+Ct6l8U0LQhlSBlDU0ajCDkCIMez8R+mMrPFZIW1n7k/qCsh5v39n3IYOE3NUg2Wvd2uEA0WaMjTZyu2O4wbaXhoRoRNqxNGFUFC3QqssRHdD69x7YjEzy4ufiyenlkKJrKStmWMdEk0zVq0PRIPPVHRjSfRefL6nAQrc3DqiWBYcr32bRk3xVfM44zOtA+zyPUtGoIKOc/w/7Vb8KE/fA8lft3telTdwS6E1vqu+OTi24PasVKmT8RIDkBbKU02wiDuGokfiizpDYuO9Mxm7NMv0UjRdQ4gSE2fsuw== 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; 12 Dec 2020 18:56:59 -0000 Received: by ary.qy (Postfix, from userid 501) id 7E9672999F42; Sat, 12 Dec 2020 13:56:58 -0500 (EST) Date: 12 Dec 2020 13:56:58 -0500 Message-Id: <20201212185658.7E9672999F42@ary.qy> From: "John Levine" To: dmarc@ietf.org Cc: vesely@tana.it In-Reply-To: <6c5878e8-fdd8-05c0-3b60-ba180ecbc391@tana.it> Organization: Taughannock Networks X-Headerized: yes Cleverness: minimal Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] Clarification of Subdomain Reporting X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 12 Dec 2020 18:57:02 -0000 In article <6c5878e8-fdd8-05c0-3b60-ba180ecbc391@tana.it> you write: >Maybe it's me, but I don't understand the change below. The only difference I >see between Old: and New: is the removal of «minOccurs="1"». Since that is the >default value, I see no incompatibility. What am I missing? If there is neither minOccurs nor maxOccurs, the field occurs exactly once. >> >> >> >> > minOccurs="0"/> >> >> > minOccurs="1"/> >> Old: >> >> > minOccurs="1"/> >> >> New: >> >> >> >> >> From nobody Sat Dec 12 10:57: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 730863A12AF for ; Sat, 12 Dec 2020 10:57:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.751 X-Spam-Level: X-Spam-Status: No, score=-1.751 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, 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=mtcc.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 dz3FsDKaAbrw for ; Sat, 12 Dec 2020 10:57:50 -0800 (PST) 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 63F213A12AE for ; Sat, 12 Dec 2020 10:57:50 -0800 (PST) Received: by mail-pg1-x52d.google.com with SMTP id t37so9599469pga.7 for ; Sat, 12 Dec 2020 10:57:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mtcc.com; s=fluffulence; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=a3dWuH8uht5DR4VPwr+l51G5+mtrF8OJ24HxTsqZ/1s=; b=SJ+eQ6XFOxC8WgBZs4UgKk9yWzwOE4YQBoQ5OVXGHIyufTAfwVUTVUV8DglYmkp7r9 TmY+CAI2BY4QMdKcGkkKXFw73RnydkbcUrdpdMbbEz0wcU4CXe63+7Q5nY9XmEXdAH7x 7SM5awpQTklrGqTFHekfI+gKYcCxcEuYsyHYL8EJLre0LrQTu459W6ZpfqJJBTJ8RaQP L8ritVRB6Bvm3DB3AGg1YTIgsn7eregf0VWdMA4hoelgIFqeAqf+rhH1RQi0VH2VkQ0G +RayC+7RN01x12gaZWUow0JXkIFjCJDcsjPTHDkHtUeh/I+RPjnW19HQOuk4S2G4qGHo osyQ== 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=a3dWuH8uht5DR4VPwr+l51G5+mtrF8OJ24HxTsqZ/1s=; b=S9JpoK8XUnlEjF56hGDvC1fxOT2K4LiYJj7SxdIhJsJOa9+AU6cZZ/UFx3DLJmDtlP eqFvJg8NkhH4z5Jj9khp8ZhacWQ4DHoNUR5O9U4Nv6W9vt2TAeYT4dXaDpAtJWj+IUV2 yzDxSV0+b9MkZzZ49rsTYvZi5Eird0D5GFiU81TxJkhL7UmOXwqwKeHv8v3mC52pX6hd 8Yok+QomsBVKg4giL24qaIWt0Z5vKnR23DXIqPsRrPzo4Do/3P25XGPPh4P2P616vvj6 04TFeXAfvZ3n5FNZONJk+7PGeBExZhe3uSAYo2MnT3YyDaWLwPhHtUHcz5rlW5X4nEyQ PwLA== X-Gm-Message-State: AOAM530RKAfgZbCAnqd0MBFkj48rWpdRFH4hKa5uk71fWTB5/4vgYxw1 CkUeDRFa+E+B7fjZOPcJNNuH2RQzN+nsHg== X-Google-Smtp-Source: ABdhPJxcT34/B4smD2HhWV4RJFWffBC9CAjZksJ2eD0cQRtpbybcffP6a3ypqi3WVgcav9T+wsJlLQ== X-Received: by 2002:a62:1a56:0:b029:19d:b6eb:291a with SMTP id a83-20020a621a560000b029019db6eb291amr17227020pfa.10.1607799469248; Sat, 12 Dec 2020 10:57:49 -0800 (PST) Received: from mike-mac.lan (107-182-41-154.volcanocom.com. [107.182.41.154]) by smtp.gmail.com with ESMTPSA id a136sm6897371pfd.149.2020.12.12.10.57.47 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 12 Dec 2020 10:57:48 -0800 (PST) To: dmarc@ietf.org References: <20201211173722.6B4DF29782C7@ary.qy> From: Michael Thomas Message-ID: Date: Sat, 12 Dec 2020 10:57:47 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.5.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] p=quarantine X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 12 Dec 2020 18:57:51 -0000 On 12/12/20 10:42 AM, Dave Crocker wrote: > > As soon as this specification text, here, contains language about how > this information is to be used, should be used, or could be used, it > crosses over into creating confusion about expectations of receiver > handling. > As a developer for 40 years, I can safely say that reject or discardable or whatever it was in ssp are all abundantly clear and that nobody writing a filter would make the error that you keep insisting that we would. The only thing all of this hand wringing has done is waste time and added to the length of time it takes to get specs out the door. Quarantine however -- which is why I started this thread -- is not clear at all. Why are we still talking about "reject"? Mike From nobody Sun Dec 13 03:00:13 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F49F3A1673 for ; Sun, 13 Dec 2020 03:00:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pXqxjhBPDtY1 for ; Sun, 13 Dec 2020 03:00:07 -0800 (PST) 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 6AA453A1674 for ; Sun, 13 Dec 2020 03:00:07 -0800 (PST) Received: (qmail 1730 invoked by uid 100); 13 Dec 2020 11:00:06 -0000 Date: 13 Dec 2020 10:59:41 -0000 Message-ID: <20201213105941.1707.qmail@submit.iecc.com> From: "John Levine" To: dmarc@ietf.org Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Archived-At: Subject: [dmarc-ietf] Messages from the dmarc list for the week ending Sun Dec 13 06:00:05 2020 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Dec 2020 11:00:09 -0000 Count | Bytes | Who ------------+----------------+------- 35 (18.8%) | 267386 (16.8%) | Michael Thomas 29 (15.6%) | 150513 ( 9.5%) | John Levine 23 (12.4%) | 120702 ( 7.6%) | Alessandro Vesely 22 (11.8%) | 182969 (11.5%) | Dave Crocker 16 ( 8.6%) | 123376 ( 7.8%) | Murray S. Kucherawy 9 ( 4.8%) | 78677 ( 5.0%) | Dotzero 7 ( 3.8%) | 89468 ( 5.6%) | Brandon Long 7 ( 3.8%) | 48746 ( 3.1%) | Kurt Andersen (b) 6 ( 3.2%) | 79035 ( 5.0%) | Jesse Thompson 6 ( 3.2%) | 76614 ( 4.8%) | Seth Blank 5 ( 2.7%) | 64064 ( 4.0%) | Douglas Foster 4 ( 2.2%) | 38227 ( 2.4%) | Tim Wicinski 4 ( 2.2%) | 33903 ( 2.1%) | Hector Santos 3 ( 1.6%) | 58087 ( 3.7%) | Brotman, Alex 2 ( 1.1%) | 31305 ( 2.0%) | Marc Bradshaw 1 ( 0.5%) | 86915 ( 5.5%) | Дилян Палаузов 1 ( 0.5%) | 18931 ( 1.2%) | Laura Atkins 1 ( 0.5%) | 11186 ( 0.7%) | Alexey Melnikov 1 ( 0.5%) | 8929 ( 0.6%) | Rich Kulawiec 1 ( 0.5%) | 6568 ( 0.4%) | Dave Warren 1 ( 0.5%) | 5134 ( 0.3%) | Jim Fenton 1 ( 0.5%) | 3990 ( 0.3%) | Benny Pedersen 1 ( 0.5%) | 2333 ( 0.1%) | IETF Meeting Session Request Tool From nobody Sun Dec 13 13:45: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 52E373A0AFA for ; Sun, 13 Dec 2020 13:45:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.803 X-Spam-Level: X-Spam-Status: No, score=0.803 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, FREEMAIL_REPLY=1, HTML_MESSAGE=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 owocn4b6PeBt for ; Sun, 13 Dec 2020 13:45:06 -0800 (PST) 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 94D623A0AF3 for ; Sun, 13 Dec 2020 13:45:06 -0800 (PST) Received: by mail-vs1-xe29.google.com with SMTP id s85so7958348vsc.3 for ; Sun, 13 Dec 2020 13:45:06 -0800 (PST) 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=ZmpTKLQjaN45r/M/xrHulgPEG5EDlzjM+XIhDb9x1FE=; b=hFf2ZFQIteSmklD5HwCNNBXJ1bSv2Pvpwj4qrNFA0ACYGB0cpvdBtmbDp08GD5FAKM qMHJhFN5Gch78CBjle9tmXS1Oyhg5XuOrb7Nt/MYwWBlDAUQj1HI257ukl/b7+SNIB0N 6qgH3ivcqjLB5Ug/IdKwma2knevfNqJuDZ/bX5ntwB/P5L+MO0IgVYSmnc6IwSXZoPKE XnZ+V4puJ5XVj0CQsBEhNKC2PnDenmwJdFmm7JmfjIwnjBZGPY+6kesifpu9r3kpWckX L76FRoWsJXIOkZVaPwCm1DkoMAzCrmtr39YPSmydtRRMEIkDiCJXX0GzbWrjN0UtVfFF Z25w== 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=ZmpTKLQjaN45r/M/xrHulgPEG5EDlzjM+XIhDb9x1FE=; b=sGcgsN9BKsOMjJne5W/l/0hChrK+UbMuHLSoRUl4E+yCT0L3cLP8N5IKpa7BOgmben 1yjac7XT/J90TZLmHvkYVlTDyS0MOxeTINZjpLJd5Do6EIUyEk9jjJfdOW0dsKDnouUs MfcIsJ8REYQLROUFJWrG2hhn8EUTEMrAAxzT5P5TpvkPr7BF/HM8W0QRCY0t1VcJ2I6S aUikIk/cZwL5HS88+yC+fPcU8EWWX/306SIsNpakN/sF3DWK0S+td2m5MRD5NVVzwXpG OJBKMm5I6UYwsO/ubOzOUHaBbeylY8hb7KRH96Vo4E3elUAcPSeT8+BB5EQWDi1zvE/p rstA== X-Gm-Message-State: AOAM532GDRZdOR99mBtff0ppijoDjZ8GODyJkv9MjdydI2GXbnpkmc3p V3pyoivvZxzr4MzCx8Vh6yVp2VtDXzgB0N1w6E7Bh/YSfKoYlQ== X-Google-Smtp-Source: ABdhPJxaNVsZT3N71JWsLJjMVn7ReAlDN09RzD+kHS0WwB99n5POI5IopJScX0Z/0LIz7YdnPHN3EkJC2+Ute1mzrBU= X-Received: by 2002:a67:507:: with SMTP id 7mr13913455vsf.42.1607895905310; Sun, 13 Dec 2020 13:45:05 -0800 (PST) MIME-Version: 1.0 References: <20201211173722.6B4DF29782C7@ary.qy> In-Reply-To: From: Douglas Foster Date: Sun, 13 Dec 2020 16:44:55 -0500 Message-ID: To: IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000459bfb05b65f70f9" Archived-At: Subject: Re: [dmarc-ietf] p=quarantine X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 13 Dec 2020 21:45:08 -0000 --000000000000459bfb05b65f70f9 Content-Type: text/plain; charset="UTF-8" Based on this discussion, it seems evident that p=reject should include language about in-transit modifications which are outside the control of the source domain, and consequently outside the ability of DMARC to guide recipients. Extending from that, I thought it would be helpful to specify some shared assumptions between sender and evaluator to make the interpretation of the settings less subjective. I call this the "Minimum expected implementation at pct=100". p=none Minimum expected implementation at pct=100: All first-party direct messages (RFC5321.MailFrom domain = RFC5322.From domain) are verifiable using SPF, but may not have a DKIM signature. Third-party direct messages ( RFC5321.MailFrom domain = RFC5322.From domain ) may or may not have DKIM signatures. Consequently, indirect messages are often not verifiable using DMARC. p=quarantine Minimum expected implementation at pct=100: All first-party direct messages (RFC5321.MailFrom domain = RFC5322.From domain) are verifiable using SPF, but may not have a DKIM signature. Third-party direct messages ( RFC5321.MailFrom domain = RFC5322.From domain ) are verifiable using DKIM signatures. Consequently, indirect messages may or may not be verifiable, depending whether the forwarded message included a signature. p=reject Minimum expected implementation at pct=100: All first-party direct messages (RFC5321.MailFrom domain matches RFC5322.From domain) are verifiable using SPF and DKIM. Third-party direct messages ( RFC5321.MailFrom domain does not match RFC5322.From domain ) are verifiable using DKIM signatures. Indirect messages which are not modified in transit are verifiable using DKIM signatures. Indirect messages which are modified in transit are outside the scope of DMARC and must be evaluated by other criteria available to the recipient system. Having defined the policies/categories in these terms, the logical next step would be a best practices document which discusses how an evaluator might distinguish between direct messages, indirect unmodified messages, and indirect modified messages. ARC obviously plays a role in making these distinctions easier to determine and less error-prone. Doug Foster On Sat, Dec 12, 2020 at 1:42 PM Dave Crocker wrote: > On 12/11/2020 9:37 AM, John Levine wrote: > > In article <1AC986FF-507B-4917-9C6D-D84E9337FC7A@wordtothewise.com> you > write: > > aligned is not authorized by the domain owner and may be discarded or > rejected by the recipient. > > Naah. > > > > p=reject: all mail sent from this domain should be aligned in a DMARC > > compliant way. We believe that unaligned mail is from unauthorized > > senders so we ask receivers to reject it, even though that might mean > > some of our authorized senders' mail is rejected too. > > > As soon as this specification text, here, contains language about how > this information is to be used, should be used, or could be used, it > crosses over into creating confusion about expectations of receiver > handling. > > It encourages misguided language such as the receiver 'overriding' > sender policy. The sender has no policies about receiver behavior, > because there is no relationship between them. Using milder language > here doesn't help, because readers typically do not read like legal or > technical scholars. > > DMARC provides information, not direction. > > The spec already contains misguided perspective by talking about > 'policy' records and, even worse, "policy enforcement considerations". > > If the document must contain language about receiver choices in message > disposition, move it to an overtly non-normative discussion section that > legitimately covers a wide range of things that receivers do or don't do > (cast as things they might or might not do.) And make sure none of the > language hints at sender 'policy', overrides, or the like. > > > d/ > > -- > Dave Crocker > dcrocker@gmail.com > 408.329.0791 > > Volunteer, Silicon Valley Chapter > American Red Cross > dave.crocker2@redcross.org > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > --000000000000459bfb05b65f70f9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Based on this discussion, it seems evident that p=3Dreject= should include language about in-transit modifications which are outside t= he control of the source domain, and consequently outside the ability of DM= ARC to guide recipients.=C2=A0 =C2=A0 Extending from that, I thought it wou= ld be helpful to specify some shared assumptions between sender and evaluat= or to make the interpretation of the settings less subjective.=C2=A0 =C2=A0= I call this the "Minimum expected implementation at pct=3D100".

p=3Dnone
Minimum expected implementation a= t pct=3D100:=C2=A0 =C2=A0=C2=A0
All first-party direct messages (= RFC5321.MailFrom domain =3D RFC5322.From domain) are verifiable using SPF, = but may not have a DKIM signature.
Third-party direct messages ( RFC5321.MailFrom domain =3D RFC5322.From domain ) may or may not have DKIM = signatures.
Consequently, indirect messages are often not verifia= ble using DMARC.

p=3Dquarantine
Minimum = expected implementation at pct=3D100:=C2=A0 =C2=A0=C2=A0
All firs= t-party direct messages (RFC5321.MailFrom domain =3D RFC5322.From domain) a= re verifiable using SPF, but may not have a DKIM signature.
Third= -party direct messages ( RFC5321.MailFrom domain =3D RFC5322.From domain ) are verifiable using DKIM= signatures.
Consequently, indirect messages may or may not be ve= rifiable, depending whether the forwarded message included a signature.

p=3Dreject
Minimum expected implementa= tion at pct=3D100:=C2=A0 =C2=A0=C2=A0
All first-party direct mess= ages (RFC5321.MailFrom domain matches RFC5322.From domain) are verifiable u= sing SPF and DKIM.
Third-party direct messages ( RFC5321.MailFrom domain does not match RFC5322.From domain ) are verifiable= using DKIM signatures.
Indirect messages which are not modified = in transit are verifiable using DKIM signatures.
Indirect message= s which are modified in transit are outside the scope of DMARC and must be = evaluated by other criteria available to the recipient system.
Having defined the policies/categories in these terms, the log= ical next step would be a best practices document which discusses how an ev= aluator might distinguish between direct messages, indirect unmodified mess= ages, and indirect modified messages.=C2=A0 =C2=A0ARC obviously plays a rol= e in making these distinctions easier to determine and less error-prone.

Doug Foster
=C2=A0

On= Sat, Dec 12, 2020 at 1:42 PM Dave Crocker <dcrocker@gmail.com> wrote:
On 12/11/2020 9:37 AM, John Levine wrote:
> In article <1AC986FF-507B-4917-9C6D-D84E9337FC7A@w= ordtothewise.com> you write:
> aligned is not authorized by the domain owner and may be discarded or = rejected by the recipient.
> Naah.
>
> p=3Dreject: all mail sent from this domain should be aligned in a DMAR= C
> compliant way. We believe that unaligned mail is from unauthorized
> senders so we ask receivers to reject it, even though that might mean<= br> > some of our authorized senders' mail is rejected too.


As soon as this specification text, here, contains language about how
this information is to be used, should be used, or could be used, it
crosses over into creating confusion about expectations of receiver
handling.

It encourages misguided language such as the receiver 'overriding' =
sender policy.=C2=A0 The sender has no policies about receiver behavior, because there is no relationship between them. Using milder language
here doesn't help, because readers typically do not read like legal or =
technical scholars.

DMARC provides information, not direction.

The spec already contains misguided perspective by talking about
'policy' records and, even worse, "policy enforcement consider= ations".

If the document must contain language about receiver choices in message disposition, move it to an overtly non-normative discussion section that legitimately covers a wide range of things that receivers do or don't d= o
(cast as things they might or might not do.)=C2=A0 And make sure none of th= e
language hints at sender 'policy', overrides, or the like.


d/

--
Dave Crocker
dcrocker@gmail.com<= /a>
408.329.0791

Volunteer, Silicon Valley Chapter
American Red Cross
dave.crocke= r2@redcross.org

_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
--000000000000459bfb05b65f70f9-- From nobody Sun Dec 13 14:41: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 E816C3A0BCC for ; Sun, 13 Dec 2020 14:41:16 -0800 (PST) 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, 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 ZPV-XTFVwmkM for ; Sun, 13 Dec 2020 14:41:15 -0800 (PST) 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 967A23A0BA9 for ; Sun, 13 Dec 2020 14:41:15 -0800 (PST) Received: by mail-qt1-x82d.google.com with SMTP id h19so10665544qtq.13 for ; Sun, 13 Dec 2020 14:41:15 -0800 (PST) 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=mHTuCEU7zXRs4/Jl//yfreh1Jv2k9f4NDWEHAwriIc8=; b=k+4ruxjAkkxDfY6ocd7Xp9dUe1OxSKgS5S3gGaLCcyNgmjkbpVGwG6OFAgoZq0gUpN wbONkea8f2nkMiqeAINaCTP0KIV5Voix2rHZvxRWPkbekSYnpM6T2fAc0Z/vUVHseStK XdiFOMHLn9tG9q3sUW8ijYuel5QQDaRttAkZLmEG9U+Jy2I3pzfsFqFeyIL5TYanhFed cpvjFiFQvrpu33IRt7KsfiJaiJWa7Q4WS+qi4Y3KxAuaYDtzwOVmT/4y/uFyj9a07Xwr JmZ2fY1w5/3T3dqPKtcLSXGwQDgTLonIxgjCfBcOS721wIW9pI7B/UEYlDCMympPMEOu 0CDg== 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=mHTuCEU7zXRs4/Jl//yfreh1Jv2k9f4NDWEHAwriIc8=; b=gN8U41qEKqoefp58OyIEFqL9NhGvGY2kWRou9ub1acKUVVW5lyL58sOfkybHl/cnGm IuC7xz4q9yNRcGQOjWvWJS33jN1x1G15TXv2BteUNBahQkcUwFxL8AoaBKSpOCHee8Mc QXWm4NCzGF4tvcpc4/So0Go7ZKsEfKgZ7SOLtBkV8wk4TeJi8qYNTc6v63Rc+y3geC2U ya+sMc78ka/thkYHmrNpMRqkMBro9Teq79UbGuVjVjgPvr8zxwpmSb5sq0wUkU549Bva sF9NI4WYCUeMM6SlHQ3UX1LLmj2HBHUkGiNAXzBfNZuiQOoRh+u8MWHP5IcZNqn/h76D AkdA== X-Gm-Message-State: AOAM533alFieG30zU0S/FksQaeMAjROcQBHT2xC2TC1u6dt8LAIF/EzJ TIJS+U8DLUi7jfLgFc/nDO9nii6HAvUzLCKavHw= X-Google-Smtp-Source: ABdhPJxidbqShMSOvSWq92VZ+QTaGaGYWxllXKkfWrtGeDLQykYoMadZGa+R9+7u8dokuAfXYWvDPnc2mZyq/LpTq2I= X-Received: by 2002:ac8:3401:: with SMTP id u1mr28514932qtb.220.1607899274523; Sun, 13 Dec 2020 14:41:14 -0800 (PST) MIME-Version: 1.0 References: <20201211173722.6B4DF29782C7@ary.qy> In-Reply-To: From: Dotzero Date: Sun, 13 Dec 2020 17:41:03 -0500 Message-ID: To: Douglas Foster Cc: IETF DMARC WG Content-Type: multipart/alternative; boundary="00000000000017b68905b6603926" Archived-At: Subject: Re: [dmarc-ietf] p=quarantine X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 13 Dec 2020 22:41:17 -0000 --00000000000017b68905b6603926 Content-Type: text/plain; charset="UTF-8" On Sun, Dec 13, 2020 at 4:45 PM Douglas Foster < dougfoster.emailstandards@gmail.com> wrote: > Based on this discussion, it seems evident that p=reject should include > language about in-transit modifications which are outside the control of > the source domain, and consequently outside the ability of DMARC to guide > recipients. > And the buzzer goes off. Sources and modifications outside the control of the domain in the RFC 5322 From is exactly what DMARC is addressing. That is exactly the guidance that is being provided by a domain publishing a DMARC record. > > Extending from that, I thought it would be helpful to specify some shared > assumptions between sender and evaluator to make the interpretation of the > settings less subjective. I call this the "Minimum expected > implementation at pct=100". > "Shared assumptions" is a poor assumption in writing a technical standard for interoperability. Having defined the policies/categories in these terms, the logical next > step would be a best practices document which discusses how an evaluator > might distinguish between direct messages, indirect unmodified messages, > and indirect modified messages. ARC obviously plays a role in making > these distinctions easier to determine and less error-prone. > "Shared assumptions" are not definitions, they are hopes. Again, not a good basis for a technical standard. Michael Hammer --00000000000017b68905b6603926 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Sun, Dec 13, 2020 at 4:45 PM Dougl= as Foster <dougfo= ster.emailstandards@gmail.com> wrote:
Based on this discussion, it = seems evident that p=3Dreject should include language about in-transit modi= fications which are outside the control of the source domain, and consequen= tly outside the ability of DMARC to guide recipients.

And the buzzer goes off. Sources and modifications ou= tside the control of the domain in the RFC 5322 From is exactly what DMARC = is addressing. That is exactly the guidance that is being provided by a dom= ain publishing a DMARC record.

Extending from that, I thought it would= be helpful to specify some shared assumptions between sender and evaluator= to make the interpretation of the settings less subjective.=C2=A0 =C2=A0I = call this the "Minimum expected implementation at pct=3D100".
=

"Shared assumptions" is a = poor assumption in writing a technical standard for interoperability.
<= /div>

<snippage>

Havin= g defined the policies/categories in these terms, the logical next step wou= ld be a best practices document which discusses how an evaluator might dist= inguish between direct messages, indirect unmodified messages, and indirect= modified messages.=C2=A0 =C2=A0ARC obviously plays a role in making these = distinctions easier to determine and less error-prone.

"Shared assumptions" are not = definitions, they are hopes. Again, not a good basis for a technical standa= rd.

Michael Hammer
--00000000000017b68905b6603926-- From nobody Mon Dec 14 01:46: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 73AB53A0EA9 for ; Mon, 14 Dec 2020 01:46:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.199 X-Spam-Level: X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5 tests=[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.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 XNzSD2OvNTsT for ; Mon, 14 Dec 2020 01:46:46 -0800 (PST) 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 01A343A0EA8 for ; Mon, 14 Dec 2020 01:46:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1607939203; bh=ntzb9MFCOX5fKfVshdm38wX1e3ZefYy6X4043eNLIws=; l=12480; h=To:References:From:Date:In-Reply-To; b=C/JMiPS6DfVZI86fPHunIMZkF8u+msozyP2A9DbwqCS+BAO2eyL0wJxS+mqEZx/EU iQ3eNfD4UXOqGEXjxh9ghKGh4J8ihhK3n8BJ7exG1JKscymzUIkfXvIYY45YyPfPo0 a4F2YALXXguI7XiMCpcP2Q+/zUq7gHibMaGyjzb60cmILfVmbnSSys/As3Mj/ Authentication-Results: tana.it; auth=pass (details omitted) Original-From: Alessandro Vesely 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 00000000005DC0C3.000000005FD73483.00000BE9; Mon, 14 Dec 2020 10:46:43 +0100 To: dmarc@ietf.org References: <160513169495.16356.6565556939968267867@ietfa.amsl.com> <3a5548b7-cb41-1533-93c3-dbecc800be19@gmail.com> From: Alessandro Vesely Message-ID: <990c30f2-d49c-94fa-3f16-87af9972ca86@tana.it> Date: Mon, 14 Dec 2020 10:46:43 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: <3a5548b7-cb41-1533-93c3-dbecc800be19@gmail.com> Content-Type: multipart/mixed; boundary="------------5125213DFB49292669BCBA4F" Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] Proposed Introduction and Abstract (was I-D Action: draft-ietf-dmarc-dmarcbis-00.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, 14 Dec 2020 09:46:47 -0000 This is a multi-part message in MIME format. --------------5125213DFB49292669BCBA4F Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On Sat 12/Dec/2020 15:45:31 +0100 Dave Crocker wrote: > Repeating from the Abstract: > > DMARC Builds on these protocols. DMARC permits the owner of an author's > domain name to enable validation of the domain's use, to indicate the > implication of failed validation, and to request reports about use of the > domain name. Mail receiving organizations can use this information when > evaluating disposition choices for incoming mail. > > The 'domain' in ADMD is not the same as in 'domain name' and, arguably, DMARC > has nothing to do with ADMDs, but only with domain names.  This is an important > distinction.  The linkage between the two comes from operational arrangement, > not anything inherent in DMARC.  I'm not sure how to reflect this fact in the > text. /d I find the phrase "owner of an author's domain name" rather ungraceful. In all of its length, it doesn't contain the word "mail". Couldn't we call it just the *mail domain*, the thing after the at-sign? The concept is so common that hardly needs using multiple words to indicate it. ADMD is a declining term, possibly confused with x'400 stuff (see ngram). I'd rather stick to *Organizational Domain*. Best Ale --------------5125213DFB49292669BCBA4F Content-Type: image/png; name="ngram.png" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="ngram.png" iVBORw0KGgoAAAANSUhEUgAABG8AAAGtBAMAAABaZUTaAAAAIVBMVEX/AAAAgAAAgIAAgP+A gICAgP//gID/gP+A/4CA//////9/+ZNlAAAACXBIWXMAAAsTAAALEwEAmpwYAAAAB3RJTUUH 5AwOCSoxVUqemwAAABl0RVh0Q29tbWVudABDcmVhdGVkIHdpdGggR0lNUFeBDhcAAB5DSURB VHja7Z09b+pMm8dTpUjnFStFdM+990qrp1tZLqDjlnd11q1FEapUFHyLSClWaVGKQxVubBbm U+51zdi8esYz9pAA/v9zknCMMYT5cb3MzDXzICDIXV8PeA8ggAMBHAjgQAAHggAOBHAggAMB HAjgQBDAgQAOBHAggAMBHAgCONDtgDM5+X++wLt+Z+DkL0Kk0f5baUs3t+GA7p6IPJxorhOG u7u2US5vqiusJvwg+cDxgn/nQ91ryflZjg5EFWetJvKlaBTHyfkx+k7Q1BcDh9stj9LJir75 d9lQ8lAo234+DnXgjMeLSnBSkdKD5He4oN+RGOteC520qAcnn8wnWnCyOIvPsAE4FwZnPKCP 82pI7TJc7Q1DSgdTMZ/MCSX6rXE0B028jQ4PRfSVLgifxThd0O1Qewl63GpYD46g16L9c7JE VIMDXdJVDahR82EucglPcfRTgkMOgv6F0lGIMakCnCgdinmUbqPVMA9fhDRadJkXgibi1k4X 24HkkCChK7ycmpIhWRN+INs26SrzKI/UbfKV2ygdsNVajUN6AqJx8nnuOAkcsjpxQg4rU99/ /5Gw+/ofOlo6srjKn0HtwJHArNgbDA4+4SU4qtXFKgyHFeCE5IfCccjgsE/j/wrJX0p3ryQ4 1N7FofCs1dVx6dcIGIKQwQnTAbtNut6WrkfwDFcv6ctqSCaMnmBwZrX+JHD+zNjKxNviWxBH DE6W8Bed9NcffwAcz+CsBvMhN/QROKHYgTNRoU8YVgTH7JPoURKcdJHzf4tQNirBEeHvUAGS h2duSPqp35Ky8Uo+P4EzpKtRSEOv6EVefjthqtmfRnTGuSvL/mQ4/hQxOy3puPjrbwInEf/8 W1okkf3xJxreMzhbtiV5VICzklYhH+zAIQMw2bXxMTi/f0twhgqcVTTZgzOf7MCZhwU4Ij1z MwVQ4SKNFmTTBmmowGHvRVwyOGRkhAJn9ULHw4pQnewNISKh+Zu/D8HJFDjiLxgc3+CILTUf NbRyWdvfRROX4AhjcHwAjhiHe3BCvkvGOEIsClcltkJUxTjpCzm0NJq//F78/q3AERTLEJfK zZGrkuDk0TAf/P5dlZDXgwP5B4camLOig6yKUxv2XQqcVJjBKVzVWAbEqexxWUnnR9QwOHRx XUdOzlkVucUFGRh6zKJ0VfmCQ5otg0PBc1SAE9JNcUbx34fg6FwVdAFwyFKsovFhP86c/sv9 OAzONh0Y+nGUL1ExzkuqLA5RktJdHPMyOGQx9L13dNKE+3JCDo7Hw12Mw8FxlP5mcKLxYEWv hrgiLyqj79N+nBKco6/S4iQA51LgcC9fSIHrvueY8p+h7DnmGCfSjRdwzzGTMo9ClY4PFDjb obxL9hwTOKtIea9qkyNTcZVmc29hAQ53XVMsLV1VGlJwnDM4dO2KdJwT7gKcrEzJkx04Ann4 RcDxo8j4X4O3+w7B4lwrONFp38q8jqxvxQbgXCs46an7OIto9AOUl1eM0YfrdVUQwIEggAMB HAjgQAAHAjgQBHAggAMBHAjgQAAHggAOBHAggAMBHAjgQBDAgQAOBHAggAMBHIADARwI4EAA BwI4EARwIIADARwI4EAAB4IADgRwIIADARwI4EAQwIEADgRwIIADARwIAjgQwIEADgRwIIAD QQAHAjgQwIEADgRwIAjgQAAHAjgQwIEADgQ1AyeLix9xwpu6Z+UvOpjwL/oJQefgxEwG/ciS uPhV3BKxPB5nGd4q6BychL74RyayA3r4gDoOcCATOPExOHSInZbkB74KsgdH3S7uJJ8Vx3jD IAtwKCqmL74zk5EzwIEqwIlPYxy2OQU4cYwgB6rMqrKKrIqzcZVcJQAHqgAnk07ptB+HXVOc 7Dt5IOgEHAgCOBDAgQAOBHAgCOBAAAcCOBDAgQAOBAEcCOBAAAcCOBDAgaBKcPR1VSJGXRWk BUdfV5XFqKuCtOBo66rY8KCuCqoB57yuSqjyGNRVQS7gnNRVQZAdODyFPUZdFWQGp6quilhJ UFcFGbKq6roqxgl1VZAOHH1dlYhRVwVpwYEggAMBHAjgQAAHggAOBHAggAMBHAjgQBDAgQAO BHAggAMBHAgCOJA/cPQFeTE2OoP04GgL8opfqKuCKsHRFuTFAgV5UC04FQV5AgV5kDM4RTEn NjqD3MBRuwCjIA8yglNVkMfsoCAPMmRVuo3OBAryIC042oK8LEZBHqQHB4IADgRwIIADARxo p00CcKAGGgUAB3JX1hslAAdy1ls/6wEcyN1TfYgA4EDOoXFPsgNwIMcQ51mIZQJwIEct+woe gAO5hTiJclcAB3JSsPsBcCC32Liz0THqqtrFxkK8JR0GB3VVTWNjwqffYXC0dVV0AHVVptiY hx0AznldVQEO6qq0sXFXo+O6jc4UOKir0sbGXY2Oazc6y1BXZYyNuxod19RVleCgrkoXG+9/ dzSr0tVVYaMznUpL083ouG6jM9WPg7qqqqTqQ3Q4OkbPcdukqkzLAQ7klFR1NMgBOG2Tqo4G OQCnbVLVUV8FcNomVczQM8CBnJMqCncCgAM5J1UMUR/gQK5JVTfDY4DTOqnqZngMcNonVfy/ HsCB7MA5tjHBB8CBHLNx+d8+wIEcs3EZ8gQAB7IC5/T/CcCBLBQYs6yugFNdVyVQV6XVWeVv 13qPjXVVsUBdlUbnXX4d81Wmuio5WR37VVWDc+aZOjbSWVflkGC/qkqdT97q2LIVddsOxQf7 VUEH4Jy/Id3yVXYWB3VVp6oopurWDFJTXdVBQR7qqurNS7cSclNdlYhRV6UFxyJD7wA41XVV +34c1FVZgNOtInL0HDdTYBf3ABzoWD2rFB3gQBbxTKeiY4DTSJWTjDsVHQOcZuA82wY+AAc6 BKcynOlSWgVwGqk6Du5SWgVwPILTpbQK4DQDJ7F3YAAHqnFKXSroBDiNpJlCAXCgGnCq86cA 4EBmcJwOAxyoBpwE4EAmBS4xM8CBaqLgDnXk1BXkZSjIAzh6cLQFeXISIAryTqUbB8+6Bo6+ IE8dBzgngPTcjt87OBXlMaquCgV5J4A8u1miDoJT1FVhozM7lwRwsNGZSdogOOgiOCjIaw/O qGPgoCDPERxdyNedOYAoyPMLTtItcCA3aYcW3gAOZJDWsCwBDmQC58M1agY4kCl5AjiQSdru mgzgQI3AeQY4kF7akYXujHICHK/gbAAOpJfBrgAcCOAAHN/g9N3DZoADmcAZARxIqyXAATiN wEn04HwAHKgJOEmnwNHXVckJ66irOpZh8sRbt8DR11Vl2OjMyawsuwWOtq6K4UFdlUMg05nh 8br9qrDRmVvqBHAq6qqgQoZevgzgHO7JiboqgKMHp6quilhJUFd1KsOAVGcm5NTUVfE36qpO ZJo70ZkJOXV1VaofB3VVtnBsugUO5AROv5kbAzgAp1HgDHA6riXAATiNwEkMd44ADqTRG8AB OE1knHPTlQk5AKcBOMY7E4ADNYh/3wAOpFGvceQMcLos86hCV+ZVABx3cJ4BDsBpIDMaGcCB moS/AAdqlHB3ZUIOwHEHp0XoDHA6LPMw5qZT4OgL8mJsdOZoUjoFjrYgrziAuir7ICboEjja grxYoCDvNBtPAI6oL8gTKMhzSqo6M6+iFpwEG525WRSAkxS7AO8K8iCbrKkj8ypqCvJk+TgK 8hxi426BY9joTKAg70i1822WXQJHW5CXxSjIOzEoHwBnDw7kLTbuyrwKgOMY4tR2DGcAB2pi TwAO1Chn6sjwOMDxHOJ0ZXgc4HgOcboyPA5wPIc4XRnlBDieQ5yuDFYBHM8hTleqxwGO7xCn I4NVAMd3iNORMQeA4yKrFQW6MeYAcJxiY5vwJQM4UJNMuxsleQDHd2zckTEH1FW5gGPlhDYd Agd1Vf5i4450HdfUVdEB1FW5xcZdBCfWgYO6KhciOtF1bAcO6qpcgpdOrB9pCQ42OnPIs5cd AyfWxzioq5JAWPbsdaIHsLauChudObugTvQA1m10pvpxUFflEvR2oiMHPcfek6pu5OMAx3tS 1Y05gADHe1LVjalcAMd7UtWNjhyAI/zj0IWpXADHe1LVjY4cgOM/qerEjByAY62e51M/0zCM FgDn7pMqB3BsjNM8DMdhGL4AHGTjLuFQGg7o5zYNI4CDbNw6ASNgJoXDulFyAI7/bLwesjws ueHbEcBBNm6Vj3+G4eKQognAuWdwfATSvxmU07gmDwEOsnHTyZRISZ1mUunwVsGprqvKUFe1 l9skm6A6sonGY/penN+xuFFwNHVVuwMoj3Gc1lcZEMkEvDo3H9woONV1VfIA9qtyz8arJ1bM 9dnT9vbiY1OVQyKNDeqqFDhJy7ONydP85pxVDTgc4+zqqjottzk2FfbJ7I5SRc7n4k7AKSwO 6qocyzPPIqJtas65t5RspZxxRZObA+esrkodQF2VPk+yzsHGYV0Us+URz/H4ZsauTHVV+wON 66o2STfBOezI2Y7ZlNj6oG0a3RA41XVVWcu6qvdRwOrFH7fPjWutVHBobMLIYfJEHg5vB5yL 6D0IKCqKmZ7er2514+xDoq0bNYqcboPzHpRG6j0Oglsnx3Ua8dt/jccLGbi4B7s3MQJxMXDe j1iJgxsPdhwLF/J//JsalmoyN/QmTM6lwHk/sTE3M397PB5X2Qi3bpw8/M9/XYw1l7IwOZPO gvN+5puCm4iQc52ZcCvODKNWK1bkUVfByc5jmpuobuTxa/FZFZg49f/No5YrVlx86CrfZf+L qwLn7bl1WvIT2ha9b/sZwRXptQ1+k5YrVqwqTE5F/85Yc5suoH6eUjEvbwzoenT/ZC4GVwVO hV+6hUVj9m1zRo7Lq5ejUu1WrDg3OavJ51mytediKBY24GxLtOny4UKCs7omcCoj4etfNOZw PtXJ59sFe5UUtVux4tzkRPKfTqdMacA5uHsbTSQ4+eSKwKnMXa9/EdejLtvjMSMHR1tMn2gZ 05315QzZ0YxTInogJ2EMKPWKKJYfMuNkICP5xGP6zzYcSHDycL7gO1fjcEF38d3kmaQ5JL+W vwwlONvhFYFT+aZdfXR8bGSOp89Y9/99lqOULVesOJ29s5XgpIt8kA+29CVCav2InQ5/EVYR fRFWhMJ8MV8wOOkiXRAak9Uwl3fR15wcVKrAWVF0w+CIawKn0rhc9yKu5328R97CBgM5vh2W lqptMjA/ntLO4Kyowcn7KJMxJAoiGeLyfQQO/Vwt6IQJ07SSAfCKKNkO5UNW0nPNi1syNh4r cAZXBE5lOHPVa398hucp+KG3sDCX3AUUjXcz0VsnA2lREqE6EZXFGXOzD2T1ZwEOIxBKcPIh AcMwcE64ks6NQRIDAodu8us7BIdc2NWBU/2eXXM+nlfNnzrs+a8Pdben3Yatk4HPEh05SnoA Djmq0uKsOMLdHoMzX+RV4IyPLQ5/Uq4NnGpErjkfr57WeWBy6pPrs24WX8kAe0CVUo0LV0Ux TWlxZLBy4qr4u3RVY+WqhiqkOQCHrpEPry3G0Til3hUbnLrDtebjfGaox2RgHBX9OGPBwTF9 FeDkQ9mLNyQSGCIVt1BQLMGh/1NwTF+lxUl34EgAyRa1BkdfkJc1KMjTRJLX25EzH9blxHXQ z8977HwvBJhKm0PGcUA3C1e1Cin1TimxTst0nMDJKSxS6Xiq0vEyxvncgTOXfcjj9v042oI8 ubi6a0Ge5rN2tav/bnXzOneDjXVj+1WlLxebD+Bhts5Bz+Bq0QYcfUGeOu4GjiaSvNoewLm+ wnJiFdjnlTWaF7Gw+ST3AM5Br99YeACnojxG1VW5FeRpCLnWZaO3+onkq4GN29GscHOZv9fP XPYdLtvJhcAp6qqcNjobOXmwNnqPYzl/I457zUq+tmNjU2yLkNfYealbGWl515vI1IHTZKMz jY323nVcVFEUahJSqHlbBi9fhMcm5re6SqhN0BFwvBXk9ZySrabajLh4YhPHXEzBc8cacEnp iXl6ZxEem8IzvcG66y0dLlCQp+vp8zvmkI3az2pe1ccLKl0amRJxrcG663WyL1CQl30LOKPe R9sPuM3iIio8DpwS8b3P/rh3cLxKB4jXD2AWtHeF88gGroVptGQbmoZ63voAxwM4XgerKsyL M5hWU8J5GEvfjWNOju/ZV10AHO0n3+PbWNkkjj2MK6seEfZF2r9oVbOWwB2Hx5cAJ7k8OJVN 6dhRZFmDQg5N9xfVrlB8xxtXXQAcbft57Neo/Ci7Rd+2VW8Uxmj+ojysm8tyx77qAuBo7bPH Uc6gfRBlXWebh/+o8oHbscUaSNc/Q/+awPm4ODgaRJyq5uzHfObBGWNydp7FFe53d85LgHP5 UFGT5rg8gUNh/+ZfThD5lHOBX5q/UIDj9Ln3B44m6HQYDXNZSiTrHQczKVeYtzKNAMcJHH+j nBoP4BAduyxetOwfpU+py652dxvkXACc3uXB0TSHfRIzj9ww3U8NrViQoJMJuX9w9NbZ35sY tEz43baIYkzZPUk5rs12twm5f3Cyy4OjZXNky83QGdNdkdPCD+MAxz6R8DY8rn0Ku/DbcTPD EtPPRmuz3euowwXA6V88N9WaLqsoynUTzHYv+16DnLq6KhG71lXp3ylv/l7brWbTSs6bp7Zr +nsNcurqqjLnjc7077O3Tg2t+bcwDu6b7rZ0NoYg571YPzzoJTcKjrauig2PY12VwV14A6cF mu7lJYF3yjfxqEQm4BnToxtcQLxuvyr3jc4M4PjKMILmzzB3Xny6ra+pePyoJKbc5WIzurkF xF3qqlpbdk/gGOxKXUdtgz0MW0e3ZzOPlzxd+v0kbOvdGTjCeaMzAziehscNkUzdaPTcvQ6y dT59tnZvpXUZPd8sOFV1VcRK4lhXNRKXBsdgA2ry8a371pfty+qyE5Oz7NmcdTNZVXVdFePk WFdlAsfPe2Ogo6aPce6+/JSHQt4TY6IxYTdWElFXVyVi17qq4IJWv/Yy5ki2yS7NHl7zsTHR lp31bhAcnzL8/Z7mw40axc3Ctq7Bf3MemZxR/7Ifq3sEx9O8iqBpp0sTg+PDgRyaHH3MtOx1 GhzTZ97PuI3RqujCqGwUBH/8e4Mm9/KmHCTbb8+X7q24UXCyi4NjHFfQecNRL/6rQf/syE/E utll4Kbk6aZ8lX9w+s3u85KN62cjE87zP0eu5Ix8eY+dGzJ119zUzPbvBcfLO2MMsTVPQZ94 7sPZbzDLvfy1GI389a0UCBpJbNRltO8m+bhtcEz2wE/GaewNqg6ApMHhPpzdlo/vQdALagaI fA4gZUHvo3ZIyuirlvRny1fck+/BsvgM0N/zF68qvBS/bhycpGmy7COp0txbGByx2/Qx5nas 2Zv4zevAY2YxfcLohJmqZ/7U8F8YfCyVbec+WrKLDM7yfsHxMq+ihr6qTy0bnHIB0XdC5r0M dkyeI/M8YL2Je/FH88RCxH0GZ9MXRN+GLA73zQqmZcOLXxE4WXLT4BjNrY+EsyZQqvrUMgK7 yk350U/qY9WfGHU0vXn9mMER/8HgZBIcNjFy8fu+BGcDcJrb8/JTmx1+uLkX5aBUfBP/sjAr PzICYPjbsuRdghOLfl8slxKcDwkORzcMjujfNjiN7/RBpnT/MmMKdmsESjhWmoIY7TyYH+lU MdAqUVHgxCLegSOPxAqc55sGJ2icEHmJjRkFuYBtvMu2pc/RrjEQ9K/H4JhwfeMYRoGzFM/H 4CzvH5yK94VnbLOS1h/KXQwjjQ2vg/zBv+QDQv3pv9iznQ7+/9AkB/14FRnRvopx+tn//nNZ xjjPnKMHyR2AY2zXk767TRwcyWaKYf2wxS5IfOcrqkA4Hxiy7v2z74KfzU9Nq1IZeyYnsMeH gdoz/5NZVZ/SqGWZVf2SG0MlPxXj6OuqYsf9qszJ8nGu/s6RSGFrNmWhSNsQ58iajMpQZ2Wo +Y3li1AMlx0tP7YPQ3b8Uer9Uh8wkf2TQZH9OH2y6suyHyeWDqv/U+Bo66qKX/blMWZPcmQu suBsjWti6bmlp6qW3TJKWVx28Pxc0cFGcSzfGblZhfxEyY/uUvUc9yUtRc/xOwU/sul+ph9H W1cVC8e6KvM45hE4lR0ldfMYGsYe1kUxI2nzrmZqjHLmho7Dg3bJPn4MnIq6KuFYV2UOQQ47 7zS2w+yKGsYeDgv+vfMH/naqnA56/WJxVeAkbnVVNeD0agkx+qJNw+7clcOyJjIwEjejPS7J VYGTJW51VeZpxYehs+PiSBtZNNtrZo5Tt8WQEgE5gFNVV1XaHOu6qpqkp1dvWaqv8K6SjIZu PERDXyyr0u1XJdzqqmoGFYJ6n1Z5B2Vg8UfjPzKP0NAX68eprqvKYse6qpqkaD/moF+qpFfF TatZSqshGvoy4PgL8nu2nsxpxYmWc3/TCRr6ysGp65/bdR0bTjyPr9su5YAQ5/rB6Vtm66aZ J89njqpdmoMQ5/rBqavV3EFhyL5OJ/tnQcuBoxQhztWDUzcEuYuBAuuLxG274xqsbQJ9NziB 5QnGWGg/NC13FW/bjTuHp7p6cDLbWRHGkYmiYLaYZ9G2XCgPkVNdPTj1Y9eFNTG7tFHvl5wf 04tb9PrtuIHBuXpwLJYjU9akzjJ5MTXg5hrB2cRn1mAT26Q/bzy7pHYRiPf2pkZqHCIyvipw 3oMTo7CJbWcjyMjl41v+uDyEvfGm9e7WzB2cTE7plvMbeC5yUEwaVhN2resURt+zAv02DV32 srv6jzi118PDrPzv9OBnZfOK9RP9eLTm4uFxdnbs8Ag91Ssf+lJP6gbOrizh1z5bLkoErm5N +fGdmZvXGWPwOjsiZH2Mz/QInEf1bcckQWKiUEJET87grJu5qs1ZCdTVQfPJG9mF0Xek4esp 6fWhEN2+2DNNnxgcaUbO7jq7IV8aG4ipAzjrmekPZW6fFDgzcZE9OX9Y27Haye7yXmo6fdjp cc/P43R2iWd7mkrH87ievs5eyfSI6euUfq5fZ18Pj1/T2fSRbjx9EVl0kN0O3SPoFP41ndIj X9nZEH50ez19mJV3vU7JSylwivvk9eVDZ7sHii8+5VGCI57uEBy5k/x48l3QPJ7YmHVx3L/l oUaU4EzXj2tq9dmrkN9kZPjra0aHn/gGnTMluhiFKRMjmC6Ci77W/PXEJ9L3Y3kF+i4sjnha T+V9fH11unog+8epegkSnEfhvyDvZ8KZUum3eKi1si1TnWVR8DxOvVqer6LFpjIYoSbd/5S8 SEfFNxibmWrnJ2mm5LG1ZOOV4ZgV1/iSHEgWSnC+Zrvr85GSlLXygl9sy/hlTIX/grxvVV6w cqDx4luoqXNH673f8mR8uM2qwPmaCgXO9OFR3vgiNh6U85nKln99kO1PJ7DRevqiOwtw6PWd gLO/Pp+uwJF+T6inmZ2Aoy3IowOuG501jGYrZTh3D0w0Hn9H1s1RsJMfWk93QZAH60MgPqkY 5xgcDkuYF+mo5I3pTEW5dC+3fGlaviQH0qqIApxHlYiV4KwPwVGuSiLEUTbDwpxVg1O17VB2 WJD3f/GV6b+nl9frw8NREOwO3P7hp9d+0Onx+DwVF8us6gScmfREX4oFeeNVlOB8vYo9OK97 VyV2ruoYnNmBq3rduaq1vN6U0eRndwJHVXtRQz10U9yMrRF/tUKk+hyZhk9lP85ZjMMhMvHC AbH0WRIxGePII3RCYXFei+BYzApw6IC8ShHRyJtPO4vzWsY4swKcmbRHR1lVLThlQR70M5Kt 9iV7jk/AWfOhxy9OmqeFsxHyIJ/I7mtN8ZhE4nU6K9LxEhw6pMB5LHuOOR1X1+fT1+UDZYT9 pQOnqiCvBKcoyLPLrnDWJc7yFNs/Ne4OOL5ZW5B3tNEZmvG2wVnP1o2D9KfjkYi6jc5UP05Z kIdmvHGL89q8b6Dd6Dia8cZdlb8OSYADcC4PDgQBHOhbwMmSg+i55qzM6iy5JrjFtWzO4l/1 Z8V217J79TVnxS5n1bz6WwZHsrBPz32cJZvS4lrC5lqx1VnC36uvO+u4O6PmrPLl3anFUauQ qrY0npVZncW9ihbXUus/ezlLeHz1NWeVg3yqR7XmLPna7xscu7fe8qzEqoHixNtZQlhdy+p1 xWYkhEQizqzOundwpDWtfeul47A5y6KBPJ9V10A+X71c57cenLgL4GSxzVvPZ9VbHDYRVmeJ mre+vJbNWewaLK6VWL16G0cbW7yuDoAjP2u1b736tjhLbhlTe1ZmdS27s+xeveW1arCPD0eN a866e3Diuhxnd1ZscVZNjuN0LctnjD2++iwx50vCKqsShQu966zKulfFZz+On16V4ixuJ2/P aLxWxta09lrlWXfcjwNBAAfyAM7/A7cjD6+lBk44AAAAAElFTkSuQmCC --------------5125213DFB49292669BCBA4F-- From nobody Mon Dec 14 02:00: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 7BDCE3A0EA5 for ; Mon, 14 Dec 2020 02:00:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.199 X-Spam-Level: X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5 tests=[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.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 5_S14s_DboOF for ; Mon, 14 Dec 2020 02:00:31 -0800 (PST) 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 843C63A0E8F for ; Mon, 14 Dec 2020 02:00:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1607940029; bh=B1YKuq2R2HWz3202tlo18juxon3FFJqRzpVWv/Hy1MY=; l=1204; h=To:References:From:Date:In-Reply-To; b=BheHj8wb945W41SH7+xjKV7/VMzN2WuAzJrK3ETd0BB/BnidXOFqyC8FK7kCljh3A s9YsNir27rcYDwi4jhJE8hC64tdEqHcnlW6WQfjj+qSabFrWsEUcwL7s3p25QYTe98 YG/jleKNfflGSX4sdvg7Ki1YT7vRDqUAbvSQcJFaQ1PF2erjhvBB1UC1rpZu1 Authentication-Results: tana.it; auth=pass (details omitted) Original-From: Alessandro Vesely 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 00000000005DC0CB.000000005FD737BD.00000DEC; Mon, 14 Dec 2020 11:00:29 +0100 To: John Levine , dmarc@ietf.org References: <20201212185658.7E9672999F42@ary.qy> From: Alessandro Vesely Message-ID: <3c73224a-0247-c392-5015-51e2d07e6921@tana.it> Date: Mon, 14 Dec 2020 11:00:29 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: <20201212185658.7E9672999F42@ary.qy> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] Clarification of Subdomain Reporting X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 14 Dec 2020 10:00:33 -0000 On Sat 12/Dec/2020 19:56:58 +0100 John Levine wrote: > In article <6c5878e8-fdd8-05c0-3b60-ba180ecbc391@tana.it> you write: >>Maybe it's me, but I don't understand the change below. The only difference I >>see between Old: and New: is the removal of «minOccurs="1"». Since that is the >>default value, I see no incompatibility. What am I missing? > > If there is neither minOccurs nor maxOccurs, the field occurs exactly once. I agree that specifying «minOccurs="1"» is redundant and could be avoided. Best Ale >>> >>> >>> >>> >> minOccurs="0"/> >>> >>> >> minOccurs="1"/> >>> Old: >>> >>> >> minOccurs="1"/> >>> >>> New: >>> >>> >>> >>> >>> -- http://www.chrismadden.co.uk/cartoon-gallery/occams-razor-ockhams-razor-too-complicated/ From nobody Mon Dec 14 02:05: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 123873A0EB9 for ; Mon, 14 Dec 2020 02:05:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.198 X-Spam-Level: X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 oDWXgQgFYzZZ for ; Mon, 14 Dec 2020 02:05:13 -0800 (PST) Received: from mail.wordtothewise.com (mail.wordtothewise.com [104.225.223.158]) by ietfa.amsl.com (Postfix) with ESMTP id 07A963A0EAF for ; Mon, 14 Dec 2020 02:05:12 -0800 (PST) Received: from [192.168.0.227] (unknown [37.228.231.27]) by mail.wordtothewise.com (Postfix) with ESMTPSA id B18A39F149 for ; Mon, 14 Dec 2020 02:05:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=wordtothewise.com; s=aardvark; t=1607940312; bh=spfbvgpoQPwjqY4ayWYXQ0gkdz6Mh6YhrCR1eF9juuY=; h=From:Subject:Date:References:To:In-Reply-To:From; b=QeUtnre0cr2L4qNRToCRvd2gyIZwDYrkXSmI58wutgWjSx7/G7hwdtID5NVNec6Og Eg/BD+1kHHVohxosvinr1C9iXkdMSPdOzJLoVbG3oL4RGd0N1+XghWf/cs1wCDSzSr sTubo4718GBr444iakYSPlCykGzspi6u++J3xw/8= From: Laura Atkins Content-Type: multipart/alternative; boundary="Apple-Mail=_A503C60D-5C74-438F-9F90-1A28BBD7D71F" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Date: Mon, 14 Dec 2020 10:05:09 +0000 References: <20201211173722.6B4DF29782C7@ary.qy> To: IETF DMARC WG In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [dmarc-ietf] p=quarantine X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 14 Dec 2020 10:05:15 -0000 --Apple-Mail=_A503C60D-5C74-438F-9F90-1A28BBD7D71F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On 13 Dec 2020, at 21:44, Douglas Foster = wrote: >=20 > Based on this discussion, it seems evident that p=3Dreject should = include language about in-transit modifications which are outside the = control of the source domain, and consequently outside the ability of = DMARC to guide recipients. Extending from that, I thought it would be = helpful to specify some shared assumptions between sender and evaluator = to make the interpretation of the settings less subjective. I call = this the "Minimum expected implementation at pct=3D100". What about messages which do not have SPF verification but do have DKIM = verification? A significant number of email platforms use their own = domains in the 5321.from address but have the customer sign with DKIM. = In many cases, DKIM signing is actually free, whereas making the SPF = align is a paid service.=20 > p=3Dnone > Minimum expected implementation at pct=3D100: =20 > All first-party direct messages (RFC5321.Mail=46rom domain =3D = RFC5322.=46rom domain) are verifiable using SPF, but may not have a DKIM = signature. > Third-party direct messages ( RFC5321.Mail=46rom domain =3D = RFC5322.=46rom domain ) may or may not have DKIM signatures. > Consequently, indirect messages are often not verifiable using DMARC. > p=3Dquarantine > Minimum expected implementation at pct=3D100: =20 > All first-party direct messages (RFC5321.Mail=46rom domain =3D = RFC5322.=46rom domain) are verifiable using SPF, but may not have a DKIM = signature. > Third-party direct messages ( RFC5321.Mail=46rom domain =3D = RFC5322.=46rom domain ) are verifiable using DKIM signatures. > Consequently, indirect messages may or may not be verifiable, = depending whether the forwarded message included a signature. >=20 > p=3Dreject > Minimum expected implementation at pct=3D100: =20 > All first-party direct messages (RFC5321.Mail=46rom domain matches = RFC5322.=46rom domain) are verifiable using SPF and DKIM. > Third-party direct messages ( RFC5321.Mail=46rom domain does not match = RFC5322.=46rom domain ) are verifiable using DKIM signatures. > Indirect messages which are not modified in transit are verifiable = using DKIM signatures. > Indirect messages which are modified in transit are outside the scope = of DMARC and must be evaluated by other criteria available to the = recipient system. >=20 > Having defined the policies/categories in these terms, the logical = next step would be a best practices document which discusses how an = evaluator might distinguish between direct messages, indirect unmodified = messages, and indirect modified messages. ARC obviously plays a role = in making these distinctions easier to determine and less error-prone. >=20 > Doug Foster > =20 >=20 > On Sat, Dec 12, 2020 at 1:42 PM Dave Crocker > wrote: > On 12/11/2020 9:37 AM, John Levine wrote: > > In article <1AC986FF-507B-4917-9C6D-D84E9337FC7A@wordtothewise.com = > you = write: > > aligned is not authorized by the domain owner and may be discarded = or rejected by the recipient. > > Naah. > > > > p=3Dreject: all mail sent from this domain should be aligned in a = DMARC > > compliant way. We believe that unaligned mail is from unauthorized > > senders so we ask receivers to reject it, even though that might = mean > > some of our authorized senders' mail is rejected too. >=20 >=20 > As soon as this specification text, here, contains language about how=20= > this information is to be used, should be used, or could be used, it=20= > crosses over into creating confusion about expectations of receiver=20 > handling. >=20 > It encourages misguided language such as the receiver 'overriding'=20 > sender policy. The sender has no policies about receiver behavior,=20 > because there is no relationship between them. Using milder language=20= > here doesn't help, because readers typically do not read like legal or=20= > technical scholars. >=20 > DMARC provides information, not direction. >=20 > The spec already contains misguided perspective by talking about=20 > 'policy' records and, even worse, "policy enforcement considerations". >=20 > If the document must contain language about receiver choices in = message=20 > disposition, move it to an overtly non-normative discussion section = that=20 > legitimately covers a wide range of things that receivers do or don't = do=20 > (cast as things they might or might not do.) And make sure none of = the=20 > language hints at sender 'policy', overrides, or the like. >=20 >=20 > d/ >=20 > --=20 > Dave Crocker > dcrocker@gmail.com > 408.329.0791 >=20 > Volunteer, Silicon Valley Chapter > American Red Cross > dave.crocker2@redcross.org >=20 > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc = > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc --=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=_A503C60D-5C74-438F-9F90-1A28BBD7D71F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

On 13 Dec 2020, at 21:44, Douglas Foster <dougfoster.emailstandards@gmail.com> wrote:

Based on this discussion, it seems evident that p=3Dreject = should include language about in-transit modifications which are outside = the control of the source domain, and consequently outside the ability = of DMARC to guide recipients.    Extending from that, I = thought it would be helpful to specify some shared assumptions between = sender and evaluator to make the interpretation of the settings less = subjective.   I call this the "Minimum expected implementation = at pct=3D100".

What= about messages which do not have SPF verification but do have DKIM = verification? A significant number of email platforms use their own = domains in the 5321.from address but have the customer sign with DKIM. = In many cases, DKIM signing is actually free, whereas making the SPF = align is a paid service. 

p=3Dnone
Minimum expected implementation = at pct=3D100:    
All first-party = direct messages (RFC5321.Mail=46rom domain =3D RFC5322.=46rom domain) = are verifiable using SPF, but may not have a DKIM signature.
Third-party direct messages ( RFC5321.Mail=46rom domain =3D RFC5322.=46rom domain ) may or may not = have DKIM signatures.
Consequently, indirect = messages are often not verifiable using = DMARC.

p=3Dquarantine
Minimum expected = implementation at pct=3D100:    
All = first-party direct messages (RFC5321.Mail=46rom domain =3D RFC5322.=46rom = domain) are verifiable using SPF, but may not have a DKIM = signature.
Third-party direct messages ( RFC5321.Mail=46rom domain =3D RFC5322.=46rom domain ) are verifiable = using DKIM signatures.
Consequently, indirect = messages may or may not be verifiable, depending whether the forwarded = message included a signature.

p=3Dreject
Minimum expected implementation at pct=3D100:  =   
All first-party direct messages = (RFC5321.Mail=46rom domain matches RFC5322.=46rom domain) are verifiable = using SPF and DKIM.
Third-party direct messages ( RFC5321.Mail=46rom domain does not match RFC5322.=46rom domain ) are = verifiable using DKIM signatures.
Indirect messages = which are not modified in transit are verifiable using DKIM = signatures.
Indirect messages which are modified in = transit are outside the scope of DMARC and must be evaluated by other = criteria available to the recipient system.

Having defined the policies/categories = in these terms, the logical next step would be a best practices document = which discusses how an evaluator might distinguish between direct = messages, indirect unmodified messages, and indirect modified = messages.   ARC obviously plays a role in making these = distinctions easier to determine and less error-prone.

Doug Foster
 

On Sat, Dec 12, 2020 at 1:42 PM Dave Crocker <dcrocker@gmail.com> = wrote:
On 12/11/2020 9:37 AM, John Levine = wrote:
> In article <1AC986FF-507B-4917-9C6D-D84E9337FC7A@wordtothewise.com> = you write:
> aligned is not authorized by the domain owner and may be discarded = or rejected by the recipient.
> Naah.
>
> p=3Dreject: all mail sent from this domain should be aligned in a = DMARC
> compliant way. We believe that unaligned mail is from = unauthorized
> senders so we ask receivers to reject it, even though that might = mean
> some of our authorized senders' mail is rejected too.


As soon as this specification text, here, contains language about how =
this information is to be used, should be used, or could be used, it
crosses over into creating confusion about expectations of receiver
handling.

It encourages misguided language such as the receiver 'overriding'
sender policy.  The sender has no policies about receiver behavior, =
because there is no relationship between them. Using milder language
here doesn't help, because readers typically do not read like legal or =
technical scholars.

DMARC provides information, not direction.

The spec already contains misguided perspective by talking about
'policy' records and, even worse, "policy enforcement = considerations".

If the document must contain language about receiver choices in message =
disposition, move it to an overtly non-normative discussion section that =
legitimately covers a wide range of things that receivers do or don't do =
(cast as things they might or might not do.)  And make sure none of = the
language hints at sender 'policy', overrides, or the like.


d/

--
Dave Crocker
dcrocker@gmail.com
408.329.0791

Volunteer, Silicon Valley Chapter
American Red Cross
dave.crocker2@redcross.org

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

-- 
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=_A503C60D-5C74-438F-9F90-1A28BBD7D71F-- From nobody Mon Dec 14 07: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 3F24D3A1252 for ; Mon, 14 Dec 2020 07:02:00 -0800 (PST) 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, 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 C6YyuCitmQ-m for ; Mon, 14 Dec 2020 07:01:58 -0800 (PST) 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 C06F73A1240 for ; Mon, 14 Dec 2020 07:01:58 -0800 (PST) Received: by mail-vs1-xe33.google.com with SMTP id q10so9089118vsr.13 for ; Mon, 14 Dec 2020 07:01:58 -0800 (PST) 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=1gpGIzhoq6gW9ALdFW7xURc5DazVfAOiZaROjAq7afQ=; b=DRbr4lYpcUg3HSUUj8jpyPwlEiOcJWFuovVI/9o9xAT3GAiU/225vGb3kqtnmbFmfr y4L1Kv43hdaTmFd3aG+AKwUgHl6jnY+WruG84RG7vsNjcNOznamDNFTBNV1+FLlV9Zch HlKnTXeRw3OV2agBnCtNX4s6yKQqCFyVLjlnGL1jO8rET489hUXG1qv+exgWyTbXHycd ICeF/EvV/kr5JHPdoShyp8aDRBVxn4uYYqReR66zrvYpjSfD6NdlIwWHq6l/NorlTC1Z cR3249FYVNaFJg4YaFIg2MhMsvws4N4lDg5QiM3fIzZ9MUKUZIY5QLLYsZMMhvN19UPr NugQ== 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=1gpGIzhoq6gW9ALdFW7xURc5DazVfAOiZaROjAq7afQ=; b=X76H1Fc0e0BToTT0NkF0Ux4texkizgA12WemBjBljl51rNpaXJFHqrvvJ1CD+OLUcp i7N2ewpekou6t8vHSQ5jSjOhueToVGLP4k+u6RJi35fvctVNtznly7xHj3A0oqMVGeY3 kRxhDqBr3LlI1+Vq/J/YP6LbJcVycOLbv+OFM5kRZ00pJ1fuXVToIbpGPteNEavXzjpB gUdDgZiXh2zEcL2YpuVxmlI2IvRJVCB+w9htONWe2ml97orFHnm05mpieoE31r9XO4Ao M01jxy8AmnlkdvIcFMxi5khOehYsnLeBb79nauncVsqs/QBgbgeawdIOL14LVjGEnt3v OXrg== X-Gm-Message-State: AOAM530DucdM/Suhor5qcgLP9+2Cpt/NcQr6e3KEi1MNzyo7t/WAiJgV UVg1slBxD2wDSr0HFvzd6dfApQ4xKvI3FWdsYWTiQR1d X-Google-Smtp-Source: ABdhPJz/hWcRqpV0o5Pna7TLR/YMs4TBpbG8rvmbYPhiYSMoa1OqZ7FM48V2DQlTFfsW0MWDye9nBFVI7voOJ09jSrk= X-Received: by 2002:a67:507:: with SMTP id 7mr17052906vsf.42.1607958117495; Mon, 14 Dec 2020 07:01:57 -0800 (PST) MIME-Version: 1.0 References: <20201211173722.6B4DF29782C7@ary.qy> In-Reply-To: From: Douglas Foster Date: Mon, 14 Dec 2020 10:01:47 -0500 Message-ID: To: IETF DMARC WG Content-Type: multipart/alternative; boundary="00000000000068395705b66dec4b" Archived-At: Subject: Re: [dmarc-ietf] p=quarantine X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 14 Dec 2020 15:02:00 -0000 --00000000000068395705b66dec4b Content-Type: text/plain; charset="UTF-8" On Sun, Dec 13, 2020 at 5:41 PM Dotzero wrote: > > > On Sun, Dec 13, 2020 at 4:45 PM Douglas Foster < > dougfoster.emailstandards@gmail.com> wrote: > >> Based on this discussion, it seems evident that p=reject should include >> language about in-transit modifications which are outside the control of >> the source domain, and consequently outside the ability of DMARC to guide >> recipients. >> > > And the buzzer goes off. Sources and modifications outside the control of > the domain in the RFC 5322 From is exactly what DMARC is addressing. That > is exactly the guidance that is being provided by a domain publishing a > DMARC record. > Do you mean that DMARC p=reject intends to block mailing lists that do content alterations, so there is not a mailing list problem at all? > > >> Extending from that, I thought it would be helpful to specify some shared >> assumptions between sender and evaluator to make the interpretation of the >> settings less subjective. I call this the "Minimum expected >> implementation at pct=100". >> > > "Shared assumptions" is a poor assumption in writing a technical standard > for interoperability. > Then change the language to SHOULD and make it a requirement. Here is the point: Sender policy is intended to help the evaluator divide incoming messages into three groups: - verifiably sent by the From domain - uncertain - verifiably NOT sent by the From domain (spoofed) The evaluator has two results to work from: Verified or Not Verified. Sender policy provides guidance for splitting the unverified messages between "uncertain" and "spoofed" by providing information about which messages SHOULD be verifiable. This is inherently a communication protocol and it has not been well defined, which is why the question has been raised, "What does p=quarantine actually mean?" It is a derivative of the earlier Chair question, "what does it mean to implement DMARC?" One could argue that anything other than "p=reject pct=100" is a non-policy which provides no useful guidance, equivalent to the SPF token ?ALL. But then we have the mailing list problem, so even at "p=reject pct=100" we have a problem with false positives (messages actually sent by the source domain but not verifiable because of in-transit changes.) So maybe DMARC has no ability to distinguish between spoofed and unverifiable messages. What seems useful is to define the capabilties and the limitations of DMARC, then define a signalling protocol so that the sender correctly signals which messages are DMARC-protected and the evaluator understands that signal in a manner which can be applied to an incoming message. I do not see that we have such a protocol at present. Rather, the evaluator is left with a lot of guesswork,and that means that the source domain owner is left with a lot of guesswork about how the recipients will make their guesses. DF --00000000000068395705b66dec4b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Sun, Dec 13, 2020 at 5:41 PM Dotze= ro <dotzero@gmail.com> wrote= :


On Sun, Dec 13, 2020 at 4:45 PM Douglas Foster <= do= ugfoster.emailstandards@gmail.com> wrote:
Based on this discussion,= it seems evident that p=3Dreject should include language about in-transit = modifications which are outside the control of the source domain, and conse= quently outside the ability of DMARC to guide recipients.

And the buzzer goes off. Sources and modification= s outside the control of the domain in the RFC 5322 From is exactly what DM= ARC is addressing. That is exactly the guidance that is being provided by a= domain publishing a DMARC record.

<= /div>
Do you mean that DMARC p=3Dreject intends to block mailing lists = that do content alterations, so there is not a mailing list problem at all?=
=C2=A0
=C2=A0

Extending from that, I thought it would = be helpful to specify some shared assumptions between sender and evaluator = to make the interpretation of the settings less subjective.=C2=A0 =C2=A0I c= all this the "Minimum expected implementation at pct=3D100".
<= /div>

"Shared assumptions" is a p= oor assumption in writing a technical standard for interoperability.

Then change the language t= o SHOULD and make it a requirement.=C2=A0 =C2=A0Here is the point:

Sender policy is intended to help the evaluator divide inc= oming messages into three groups:
- verifiably sent by the From d= omain
- uncertain
- verifiably NOT sent by the From dom= ain (spoofed)

The evaluator has two results to wor= k from:=C2=A0 =C2=A0Verified or Not Verified.=C2=A0 =C2=A0Sender policy pro= vides guidance for splitting the unverified messages between "uncertai= n" and "spoofed" by providing information about which messag= es SHOULD be verifiable.=C2=A0 =C2=A0 =C2=A0This is inherently a communicat= ion protocol and it has not been well defined, which is why the question ha= s been raised, "What does p=3Dquarantine actually mean?"=C2=A0 = =C2=A0It is a derivative of the earlier Chair question, "what does it= =C2=A0 mean to implement DMARC?"

One coul= d argue that anything other than "p=3Dreject pct=3D100" is a non-= policy which provides no useful guidance, equivalent to the SPF token ?ALL.= =C2=A0 =C2=A0But then we have the mailing list problem, so even at "p= =3Dreject pct=3D100" we have a problem with false positives (messages = actually sent by the source domain but not verifiable because of in-transit= changes.)=C2=A0 =C2=A0So maybe DMARC has no ability to distinguish between= spoofed and unverifiable messages.

What seems use= ful is to define the capabilties and the limitations of DMARC, then define = a signalling protocol so that the sender correctly signals which messages a= re DMARC-protected and the evaluator understands that signal in a manner wh= ich can be applied to an incoming message.=C2=A0 =C2=A0 I do not see that w= e have such a protocol at present.=C2=A0 =C2=A0Rather, the evaluator is lef= t with a lot of guesswork,and that means that the source domain owner is le= ft with a lot of guesswork about how the recipients will make their=C2=A0gu= esses.

DF
--00000000000068395705b66dec4b-- From nobody Mon Dec 14 07:10: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 66EF43A12C8 for ; Mon, 14 Dec 2020 07:10:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.199 X-Spam-Level: X-Spam-Status: No, score=-0.199 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, 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 5BMM5PbE0Xpz for ; Mon, 14 Dec 2020 07:10:39 -0800 (PST) Received: from mail-pg1-x529.google.com (mail-pg1-x529.google.com [IPv6:2607:f8b0:4864:20::529]) (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 4AD463A12A3 for ; Mon, 14 Dec 2020 07:10:39 -0800 (PST) Received: by mail-pg1-x529.google.com with SMTP id w16so12617947pga.9 for ; Mon, 14 Dec 2020 07:10:39 -0800 (PST) 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=ADK8fnQuXMFFy6tGRY8pW9tof3TJmA+FXukgpIdAPMg=; b=V9hwRUfSfoxrI8/gmlLJ9A44W3KOwPg4/P8O1cJ0AwnBMdR1gWB9eh4Nw9fr7YhWOU ubWfSGiczI4XUiTmv6OXAd3y5O3FVyQaDsAfMPShcSqu5CKP5ESLt3ccbNCDnDzA1GCO RrbDApnL6U01o1BNbly97mfKytTsdan8mpjnIhMZFeAUfQl4LxxxtEl8PSfxN2JGjWBH oZriKOjjkP3zoCWDabkltR6LFqAKhPJxqrFett3ldK/sCoxsRXJ5QDmddUqc48w3GwWB 3yR+qyOa9jh0lvXwrSMKQjCnCI2HUtnSEyWQMt7HVjP2LPkNpBOVuTqrPIB6d542zA9X l08A== 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=ADK8fnQuXMFFy6tGRY8pW9tof3TJmA+FXukgpIdAPMg=; b=sidioJbPJ7J+wi+ymmmW82uZqMJiOlFCtJQEot7iRlwEp/g/kHUZCQoeFAV+uLQ0yJ fU8EvxFEQrp3hfTASu+8NmYSvzyx3j6LAeTOLs1Kkc6jw6mjqGEH+CqJkGJXCHOzg7LX GJIqfDaBwXXbxfwfdsK9ZG1tbJU0+tr06nZonAjkyC77mzt7OsKZn8t6pu2aHzkctLhu nlwlR+8GLZQsPCE65sZavTYbtd8FdBwT+GOG+XKhKToKCeqt9sswCPeSJqdRlypTGTxB gTDL1B3s3oy4M1BAxscL4iOgto4gXfYc7wKVKLLovXWBq/RdJRc2q/4g+IubeWp0btrn Ad0g== X-Gm-Message-State: AOAM5320uXpRuOxVIQQ9oV3jklGLMsiUpXoYGvyUoCpmuNNOPu+dpBh1 gB/yAJLbVoWaXTJGIi8fx8jobHjggp8= X-Google-Smtp-Source: ABdhPJw8q8QymXfbg9tQ8S0ranpYmxYtsjjVKunXFIaBRG7QeMrdz9W3hOM584jk29hqkLGU51+9MQ== X-Received: by 2002:a62:a509:0:b029:19e:1ac3:34bc with SMTP id v9-20020a62a5090000b029019e1ac334bcmr24223673pfm.7.1607958638384; Mon, 14 Dec 2020 07:10:38 -0800 (PST) Received: from [192.168.0.109] (c-24-130-62-181.hsd1.ca.comcast.net. [24.130.62.181]) by smtp.gmail.com with ESMTPSA id jx4sm18009353pjb.24.2020.12.14.07.10.37 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 14 Dec 2020 07:10:37 -0800 (PST) To: John R Levine , dmarc@ietf.org References: <20201211173722.6B4DF29782C7@ary.qy> <6dc2d62e-e288-8d8f-44b2-6f42e7e580@taugh.com> From: Dave Crocker Message-ID: Date: Mon, 14 Dec 2020 07:10:36 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.5.1 MIME-Version: 1.0 In-Reply-To: <6dc2d62e-e288-8d8f-44b2-6f42e7e580@taugh.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] p=quarantine X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 14 Dec 2020 15:10:40 -0000 On 12/12/2020 10:51 AM, John R Levine wrote: > On Sat, 12 Dec 2020, Dave Crocker wrote: >>> p=reject: all mail sent from this domain should be aligned in a DMARC >>> compliant way. We believe that unaligned mail is from unauthorized >>> senders so we ask receivers to reject it, even though that might mean >>> some of our authorized senders' mail is rejected too. >> >> As soon as this specification text, here, contains language about how >> this information is to be used, should be used, or could be used, it >> crosses over into creating confusion about expectations of receiver >> handling. > > I agree with you, which is why I said "believe" and "request". Except that that runs contrary to my point, rather than being compatible with it. Any an all discussion of receiver /use/ of DMARC needs to be moved to a separate section and it needs to refrain from any linguistic form that characterizes that use as being in response to domain owner desires. > > If we're going to have any description of p=none at all it needs to > emphasize the point that it's telling you that they consider the > messages unusually unimportant.  This appears to be at odds with what > some DMARC users believe. It isn't about the 'importance' of the messages.  It is about the domain owner's view of the implication of the success or failure of DMARC validation. d/ -- Dave Crocker dcrocker@gmail.com 408.329.0791 Volunteer, Silicon Valley Chapter American Red Cross dave.crocker2@redcross.org From nobody Mon Dec 14 07:12: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 41A613A12E7 for ; Mon, 14 Dec 2020 07:12:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.803 X-Spam-Level: X-Spam-Status: No, score=0.803 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, FREEMAIL_REPLY=1, HTML_MESSAGE=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 EEAHrglYUODh for ; Mon, 14 Dec 2020 07:12:02 -0800 (PST) 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 1CDEA3A12E3 for ; Mon, 14 Dec 2020 07:12:02 -0800 (PST) Received: by mail-vs1-xe36.google.com with SMTP id q10so9108715vsr.13 for ; Mon, 14 Dec 2020 07:12:02 -0800 (PST) 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=skoBLoJt0GkHexFmpym3hywoB/0sC9nLGbDlKhWpNWY=; b=Lar06MxzLiloMiSn4yJJWi3g+QevWHHSwkvHIUnAVtF2J0Z5thC7AWs8H14Jnhgo6p 50gAes5J3p/K+70bPmNzEBdNh7rHodvaFNdl1gJzorWeUyyaf/GNsC+U8eUwcCQWjhyy 3ZIewKsA3CUGFFEaa+khX5f4giIyqFRC5EXQbSg9zrbW506gSHhfQZFffk9tZhs8kouN kiYxMWgR+PFFyv0dFRnTMb5a7VBIzYHcVRU5woA28Ns6c6Ka8BPNcxF1I9ETH5RBGVTG 7uhC1fVRU45sf+dUAP0swSNm7UytqkhBf0aYD1Z536zu2xzpTOL6Nd4AdFTnZdT4AjYo Glzg== 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=skoBLoJt0GkHexFmpym3hywoB/0sC9nLGbDlKhWpNWY=; b=oE5eqmV6OHApbCRg09jEZVKVQMNlSlVmvc/IHiBiIaZ8K9FgRJ8vmPR4L6Colb71Ld pRgPLxDfAaHQJZkJzPnFruLD1x61HZcT+TTDaEeK/3ThRQVZVIaRZ0bqXBmBgsiM2HH5 j0BOsw9V+RazkhIBOGHc+rMT/VP99Q6S0U4x3luOcXueBe07i5IPAfMzug8b2j4FGlYx tOVt1k3xrcjqYKR84yojyqZFiFzjP4AGMSo7IYflL64U+SDstIttWOTjxB7vOK+4igCk 0fqFKCLUJFPXo04wy87Xg19OROa08ZMplzpJ3l1Ddwaq3w5xs9DF5mrPkcT4qIHX1wcY S+/w== X-Gm-Message-State: AOAM532D0E0VKnlmnZkNyA9V69gYXiWlZL1wUn+izxLOaXRbht121kzH ky5C1cunW2ewskWPMdp+BTCGBqQM1NTePlSliXN0NAgY X-Google-Smtp-Source: ABdhPJzyTQonLnbyWTpDV7JlJcqYw8B13BrG6rY+xOT/w+ckEEG8CF1oP4zFeixjtbcC4RgZiYMfGy17cyNmpil9Z+A= X-Received: by 2002:a67:c983:: with SMTP id y3mr1647029vsk.59.1607958719698; Mon, 14 Dec 2020 07:11:59 -0800 (PST) MIME-Version: 1.0 References: <20201211173722.6B4DF29782C7@ary.qy> In-Reply-To: From: Douglas Foster Date: Mon, 14 Dec 2020 10:11:48 -0500 Message-ID: To: IETF DMARC WG Content-Type: multipart/alternative; boundary="0000000000004d18a205b66e10bd" Archived-At: Subject: Re: [dmarc-ietf] p=quarantine X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 14 Dec 2020 15:12:04 -0000 --0000000000004d18a205b66e10bd Content-Type: text/plain; charset="UTF-8" I called that a third-party message, since the RFC5321.MailFrom domain is different from the RFC5322.From domain. I am open to revisions of how the boundaries should be defined, but as I said in my reply just now to Michael Hammer, we need to define those boundaries in a way that both sender and receiver understand. This is the full problem description: We have these three types of senders: - first-party senders - third-party senders - spoofers We have these four verification states at initial transmission: - none - spf only - dkim only - spf and dkim We have these 9 routing scenarios: - direct (1) - indirect (8) with and without SMTP rewrite with and without FROM rewrite with and without content modifications Upon receipt, we have these verification states: - Not verified - SPF only - DKIM only - SPF and DKIM For messages that do not verify, the evaluator uses sender policy (none, quarantine, reject) to categorize the message as either "verifiably spoofed" or "uncertain". What is the algorithm for doing so? DF On Mon, Dec 14, 2020 at 5:05 AM Laura Atkins wrote: > > > On 13 Dec 2020, at 21:44, Douglas Foster < > dougfoster.emailstandards@gmail.com> wrote: > > Based on this discussion, it seems evident that p=reject should include > language about in-transit modifications which are outside the control of > the source domain, and consequently outside the ability of DMARC to guide > recipients. Extending from that, I thought it would be helpful to > specify some shared assumptions between sender and evaluator to make the > interpretation of the settings less subjective. I call this the "Minimum > expected implementation at pct=100". > > > What about messages which do not have SPF verification but do have DKIM > verification? A significant number of email platforms use their own domains > in the 5321.from address but have the customer sign with DKIM. In many > cases, DKIM signing is actually free, whereas making the SPF align is a > paid service. > > p=none > Minimum expected implementation at pct=100: > All first-party direct messages (RFC5321.MailFrom domain = RFC5322.From > domain) are verifiable using SPF, but may not have a DKIM signature. > Third-party direct messages ( RFC5321.MailFrom domain = RFC5322.From > domain ) may or may not have DKIM signatures. > Consequently, indirect messages are often not verifiable using DMARC. > > > p=quarantine > Minimum expected implementation at pct=100: > All first-party direct messages (RFC5321.MailFrom domain = RFC5322.From > domain) are verifiable using SPF, but may not have a DKIM signature. > Third-party direct messages ( RFC5321.MailFrom domain = RFC5322.From > domain ) are verifiable using DKIM signatures. > Consequently, indirect messages may or may not be verifiable, depending > whether the forwarded message included a signature. > > p=reject > Minimum expected implementation at pct=100: > All first-party direct messages (RFC5321.MailFrom domain matches > RFC5322.From domain) are verifiable using SPF and DKIM. > Third-party direct messages ( RFC5321.MailFrom domain does not match > RFC5322.From domain ) are verifiable using DKIM signatures. > Indirect messages which are not modified in transit are verifiable using > DKIM signatures. > Indirect messages which are modified in transit are outside the scope of > DMARC and must be evaluated by other criteria available to the recipient > system. > > Having defined the policies/categories in these terms, the logical next > step would be a best practices document which discusses how an evaluator > might distinguish between direct messages, indirect unmodified messages, > and indirect modified messages. ARC obviously plays a role in making > these distinctions easier to determine and less error-prone. > > Doug Foster > > > On Sat, Dec 12, 2020 at 1:42 PM Dave Crocker wrote: > >> On 12/11/2020 9:37 AM, John Levine wrote: >> > In article <1AC986FF-507B-4917-9C6D-D84E9337FC7A@wordtothewise.com> >> you write: >> > aligned is not authorized by the domain owner and may be discarded or >> rejected by the recipient. >> > Naah. >> > >> > p=reject: all mail sent from this domain should be aligned in a DMARC >> > compliant way. We believe that unaligned mail is from unauthorized >> > senders so we ask receivers to reject it, even though that might mean >> > some of our authorized senders' mail is rejected too. >> >> >> As soon as this specification text, here, contains language about how >> this information is to be used, should be used, or could be used, it >> crosses over into creating confusion about expectations of receiver >> handling. >> >> It encourages misguided language such as the receiver 'overriding' >> sender policy. The sender has no policies about receiver behavior, >> because there is no relationship between them. Using milder language >> here doesn't help, because readers typically do not read like legal or >> technical scholars. >> >> DMARC provides information, not direction. >> >> The spec already contains misguided perspective by talking about >> 'policy' records and, even worse, "policy enforcement considerations". >> >> If the document must contain language about receiver choices in message >> disposition, move it to an overtly non-normative discussion section that >> legitimately covers a wide range of things that receivers do or don't do >> (cast as things they might or might not do.) And make sure none of the >> language hints at sender 'policy', overrides, or the like. >> >> >> d/ >> >> -- >> Dave Crocker >> dcrocker@gmail.com >> 408.329.0791 >> >> Volunteer, Silicon Valley Chapter >> American Red Cross >> dave.crocker2@redcross.org >> >> _______________________________________________ >> dmarc mailing list >> dmarc@ietf.org >> https://www.ietf.org/mailman/listinfo/dmarc >> > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > > > -- > 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 > > > > > > > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > --0000000000004d18a205b66e10bd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I called that a third-party message, since the RFC5321.Mai= lFrom domain is different from the RFC5322.From domain.

= I am open to revisions of how the boundaries should be defined, but as I sa= id in my reply just now to Michael Hammer, we need to define those boundari= es in a way that both sender and receiver understand.=C2=A0 This is the ful= l problem description:

We have these three types o= f senders:
- first-party senders
- third-party senders<= /div>
- spoofers

We have these four verificati= on states at initial transmission:
- none
- spf only
- dkim only
- spf and dkim

We ha= ve these 9 routing scenarios:
- direct (1)
- indirect (= 8)
=C2=A0 =C2=A0 with and without SMTP rewrite
=C2=A0 = =C2=A0 with and without FROM rewrite
=C2=A0 =C2=A0 with and witho= ut content modifications

Upon receipt, we have the= se verification states:
- Not verified
- SPF only
=
- DKIM only
- SPF and DKIM

For mess= ages that do not verify, the evaluator uses sender policy (none, quarantine= , reject) to categorize the message as either "verifiably spoofed"= ; or "uncertain".=C2=A0 =C2=A0What is the algorithm for doing so?=

DF


On Mon, Dec 14, 2020 at 5:= 05 AM Laura Atkins <laura@wor= dtothewise.com> wrote:


On 13 Dec 2020, at 21:44, Douglas Foster <dougfos= ter.emailstandards@gmail.com> wrote:

= Based on this discussion, it seems evident that p=3Dreject should include l= anguage about in-transit modifications which are outside the control of the= source domain, and consequently outside the ability of DMARC to guide reci= pients.=C2=A0 =C2=A0 Extending from that, I thought it would be helpful to = specify some shared assumptions between sender and evaluator to make the in= terpretation of the settings less subjective.=C2=A0 =C2=A0I call this the &= quot;Minimum expected implementation at pct=3D100".

What about messages which do not have SPF verific= ation but do have DKIM verification? A significant number of email platform= s use their own domains in the 5321.from address but have the customer sign= with DKIM. In many cases, DKIM signing is actually free, whereas making th= e SPF align is a paid service.=C2=A0

p=3Dnone
Minimum expected implementation = at pct=3D100:=C2=A0 =C2=A0=C2=A0
All first-party direct messages = (RFC5321.MailFrom domain =3D RFC5322.From domain) are verifiable using SPF,= but may not have a DKIM signature.
Third-party direct messages ( RFC5321.MailFrom domain =3D RFC5322.From domain ) may or may not have DKIM = signatures.
Consequently, indirect messages are often not verifia= ble using DMARC.

p=3Dquarantine
Minimum ex= pected implementation at pct=3D100:=C2=A0 =C2=A0=C2=A0
All first-= party direct messages (RFC5321.MailFrom domain =3D RFC5322.From domain) are= verifiable using SPF, but may not have a DKIM signature.
Third-p= arty direct messages ( RFC5321.MailFrom domain =3D RFC5322.From domain ) are verifiable using DKIM= signatures.
Consequently, indirect messages may or may not be ve= rifiable, depending whether the forwarded message included a signature.

p=3Dreject
Minimum expected implementa= tion at pct=3D100:=C2=A0 =C2=A0=C2=A0
All first-party direct mess= ages (RFC5321.MailFrom domain matches RFC5322.From domain) are verifiable u= sing SPF and DKIM.
Third-party direct messages ( RFC5321.MailFrom domain does not match RFC5322.From domain ) are verifiable= using DKIM signatures.
Indirect messages which are not modified = in transit are verifiable using DKIM signatures.
Indirect message= s which are modified in transit are outside the scope of DMARC and must be = evaluated by other criteria available to the recipient system.
Having defined the policies/categories in these terms, the log= ical next step would be a best practices document which discusses how an ev= aluator might distinguish between direct messages, indirect unmodified mess= ages, and indirect modified messages.=C2=A0 =C2=A0ARC obviously plays a rol= e in making these distinctions easier to determine and less error-prone.

Doug Foster
=C2=A0

On= Sat, Dec 12, 2020 at 1:42 PM Dave Crocker <dcrocker@gmail.com> wrote:
On 12/11/2020 9:37 AM, John L= evine wrote:
> In article <1AC986FF-507B-4917-9C6D-D84E9337FC7A@w= ordtothewise.com> you write:
> aligned is not authorized by the domain owner and may be discarded or = rejected by the recipient.
> Naah.
>
> p=3Dreject: all mail sent from this domain should be aligned in a DMAR= C
> compliant way. We believe that unaligned mail is from unauthorized
> senders so we ask receivers to reject it, even though that might mean<= br> > some of our authorized senders' mail is rejected too.


As soon as this specification text, here, contains language about how
this information is to be used, should be used, or could be used, it
crosses over into creating confusion about expectations of receiver
handling.

It encourages misguided language such as the receiver 'overriding' =
sender policy.=C2=A0 The sender has no policies about receiver behavior, because there is no relationship between them. Using milder language
here doesn't help, because readers typically do not read like legal or =
technical scholars.

DMARC provides information, not direction.

The spec already contains misguided perspective by talking about
'policy' records and, even worse, "policy enforcement consider= ations".

If the document must contain language about receiver choices in message disposition, move it to an overtly non-normative discussion section that legitimately covers a wide range of things that receivers do or don't d= o
(cast as things they might or might not do.)=C2=A0 And make sure none of th= e
language hints at sender 'policy', overrides, or the like.


d/

--
Dave Crocker
dcrocker@gmail.com<= /a>
408.329.0791

Volunteer, Silicon Valley Chapter
American Red Cross
dave.crocke= r2@redcross.org

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

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

Laur= a Atkins
Word to the Wise
(650)= 437-0741

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







_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
--0000000000004d18a205b66e10bd-- From nobody Mon Dec 14 07:31: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 624AE3A0BAD for ; Mon, 14 Dec 2020 07:31:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.198 X-Spam-Level: X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 xfUCSbkd0SXD for ; Mon, 14 Dec 2020 07:31:45 -0800 (PST) Received: from mail.wordtothewise.com (mail.wordtothewise.com [104.225.223.158]) by ietfa.amsl.com (Postfix) with ESMTP id 113333A0BA9 for ; Mon, 14 Dec 2020 07:31:44 -0800 (PST) Received: from [192.168.0.227] (unknown [37.228.231.27]) by mail.wordtothewise.com (Postfix) with ESMTPSA id 6251A9F149; Mon, 14 Dec 2020 07:31:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=wordtothewise.com; s=aardvark; t=1607959904; bh=5P7Lxv0CMjIz0tPqmWKpx73zes3QE8Rizy7CabEu6Sc=; h=From:Subject:Date:In-Reply-To:Cc:To:References:From; b=GnGnhXCyhm3gdvrCza92xFYksQ6ucodkjZa/js/U1nTt4Kc0O0VyS94OpqHdWcS2y keGFOshx6NERCvac6sPi7lg4uiDOauwytIot2BUIj/qD9d1abeQTAZbniCRSMnlF5E bbJ6SSRGKpPMy+Qj7XlahAMikIfMarVJ61EsAfIU= From: Laura Atkins Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_C843D70D-3B65-4C1D-ACB3-F2B2F907DB5D" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Date: Mon, 14 Dec 2020 15:31:41 +0000 In-Reply-To: Cc: John Levine , dmarc@ietf.org To: Dave Crocker References: <20201211173722.6B4DF29782C7@ary.qy> <6dc2d62e-e288-8d8f-44b2-6f42e7e580@taugh.com> X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [dmarc-ietf] p=quarantine X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 14 Dec 2020 15:31:46 -0000 --Apple-Mail=_C843D70D-3B65-4C1D-ACB3-F2B2F907DB5D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 14 Dec 2020, at 15:10, Dave Crocker wrote: >=20 > On 12/12/2020 10:51 AM, John R Levine wrote: >> On Sat, 12 Dec 2020, Dave Crocker wrote: >>>> p=3Dreject: all mail sent from this domain should be aligned in a = DMARC >>>> compliant way. We believe that unaligned mail is from unauthorized >>>> senders so we ask receivers to reject it, even though that might = mean >>>> some of our authorized senders' mail is rejected too. >>>=20 >>> As soon as this specification text, here, contains language about = how this information is to be used, should be used, or could be used, it = crosses over into creating confusion about expectations of receiver = handling. >>=20 >> I agree with you, which is why I said "believe" and "request". >=20 > Except that that runs contrary to my point, rather than being = compatible with it. >=20 > Any an all discussion of receiver /use/ of DMARC needs to be moved to = a separate section and it needs to refrain from any linguistic form that = characterizes > that use as being in response to domain owner desires. =E2=80=98As a matter of policy we treat all unaligned mail as = unauthorized use of our domain.=E2=80=99=20 I am agnostic about moving the =E2=80=98what to do=E2=80=99 section. I = think it makes sense to keep the sender definitions and the ways = receivers can interpret those declarations close together.=20 >> If we're going to have any description of p=3Dnone at all it needs to = emphasize the point that it's telling you that they consider the = messages unusually unimportant. This appears to be at odds with what = some DMARC users believe. >=20 > It isn't about the 'importance' of the messages. It is about the = domain owner's view of the implication of the success or failure of = DMARC validation. The current p=3Dreject is that the domain owner=E2=80=99s view is that = the mail is unauthorized. And, according to discussion here on the IETF = list, we are to presume that every domain owner knows exactly what they = are doing and that every company understands the implications of a = p=3Dreject policy statement.=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=_C843D70D-3B65-4C1D-ACB3-F2B2F907DB5D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On 14 Dec 2020, at 15:10, Dave Crocker <dcrocker@gmail.com> = wrote:

On 12/12/2020 10:51 AM, John R Levine wrote:
On Sat, 12 Dec 2020, = Dave Crocker wrote:
p=3Dreject: all mail = sent from this domain should be aligned in a DMARC
compliant= way. We believe that unaligned mail is from unauthorized
senders so we ask receivers to reject it, even though that = might mean
some of our authorized senders' mail is = rejected too.

As soon as this = specification text, here, contains language about how this information = is to be used, should be used, or could be used, it crosses over into = creating confusion about expectations of receiver handling.

I agree with you, which is why I = said "believe" and "request".

Except that that runs contrary to my point, rather than being = compatible with it.

Any an all discussion = of receiver /use/ of DMARC needs to be moved to a separate section and = it needs to refrain from any linguistic form that = characterizes
that use as being in response = to domain owner desires.

=E2=80=98As a matter of policy we treat all unaligned = mail as unauthorized use of our domain.=E2=80=99 

I am agnostic about moving the =E2=80=98what to = do=E2=80=99 section. I think it makes sense to keep the sender = definitions and the ways receivers can interpret those declarations = close together. 

If we're going to have any description of = p=3Dnone at all it needs to emphasize the point that it's telling you = that they consider the messages unusually unimportant.  This = appears to be at odds with what some DMARC users believe.

It isn't about the 'importance' = of the messages.  It is about the domain owner's view of the = implication of the success or failure of DMARC validation.

The = current p=3Dreject is that the domain owner=E2=80=99s view is that the = mail is unauthorized. And, according to discussion here on the IETF = list, we are to presume that every domain owner knows exactly what they = are doing and that every company understands the implications of a = p=3Dreject policy statement. 

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=_C843D70D-3B65-4C1D-ACB3-F2B2F907DB5D-- From nobody Mon Dec 14 07:36: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 387B53A0EAD for ; Mon, 14 Dec 2020 07:36:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.198 X-Spam-Level: X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 YXhIreP_YLnM for ; Mon, 14 Dec 2020 07:36:43 -0800 (PST) Received: from mail.wordtothewise.com (mail.wordtothewise.com [104.225.223.158]) by ietfa.amsl.com (Postfix) with ESMTP id 8AE003A0EA9 for ; Mon, 14 Dec 2020 07:36:43 -0800 (PST) Received: from [192.168.0.227] (unknown [37.228.231.27]) by mail.wordtothewise.com (Postfix) with ESMTPSA id 2B4369F149 for ; Mon, 14 Dec 2020 07:36:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=wordtothewise.com; s=aardvark; t=1607960202; bh=ttH5ExMc7nGAS5nsNEPwiUx5r9nVYmJvDNKZXuyJnnc=; h=From:Subject:Date:References:To:In-Reply-To:From; b=riJpSWbEWNUPEg+L3ul70FZfOMP6a6Byg9ocBHbT26RHMakTn1ZFxf5RmFCMhHDRk bAhc5+cFBm5oqSkJl6I7aHUX0JzHQZd55KsxHusxsICWV+m6Hzn06fCpxUOq5TsaR1 SxAPxvadknpXsW5E7vtKZpISD8VIBhYzWC+JndDI= From: Laura Atkins Content-Type: multipart/alternative; boundary="Apple-Mail=_5FC61C73-60FA-4C02-AD14-F6CA0DE17897" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Date: Mon, 14 Dec 2020 15:36:40 +0000 References: <20201211173722.6B4DF29782C7@ary.qy> To: IETF DMARC WG In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [dmarc-ietf] p=quarantine X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 14 Dec 2020 15:36:46 -0000 --Apple-Mail=_5FC61C73-60FA-4C02-AD14-F6CA0DE17897 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 14 Dec 2020, at 15:11, Douglas Foster = wrote: >=20 > I called that a third-party message, since the RFC5321.Mail=46rom = domain is different from the RFC5322.=46rom domain. No, you didn=E2=80=99t. Third-party direct messages ( RFC5321.Mail=46rom domain =3D RFC5322.=46rom= domain ) I think =E2=80=98first party=E2=80=99 and =E2=80=99third-party=E2=80=99 = are problematic definitions in any case and I=E2=80=99m not sure I = understand what your goal is here. Who are you considering =E2=80=98party=E2= =80=99? laura > I am open to revisions of how the boundaries should be defined, but as = I said in my reply just now to Michael Hammer, we need to define those = boundaries in a way that both sender and receiver understand. This is = the full problem description: >=20 > We have these three types of senders: > - first-party senders > - third-party senders > - spoofers >=20 > We have these four verification states at initial transmission: > - none > - spf only > - dkim only > - spf and dkim >=20 > We have these 9 routing scenarios: > - direct (1) > - indirect (8) > with and without SMTP rewrite > with and without FROM rewrite > with and without content modifications >=20 > Upon receipt, we have these verification states: > - Not verified > - SPF only > - DKIM only > - SPF and DKIM >=20 > For messages that do not verify, the evaluator uses sender policy = (none, quarantine, reject) to categorize the message as either = "verifiably spoofed" or "uncertain". What is the algorithm for doing = so? >=20 > DF >=20 >=20 > On Mon, Dec 14, 2020 at 5:05 AM Laura Atkins > wrote: >=20 >=20 >> On 13 Dec 2020, at 21:44, Douglas Foster = > wrote: >>=20 >> Based on this discussion, it seems evident that p=3Dreject should = include language about in-transit modifications which are outside the = control of the source domain, and consequently outside the ability of = DMARC to guide recipients. Extending from that, I thought it would be = helpful to specify some shared assumptions between sender and evaluator = to make the interpretation of the settings less subjective. I call = this the "Minimum expected implementation at pct=3D100". >=20 > What about messages which do not have SPF verification but do have = DKIM verification? A significant number of email platforms use their own = domains in the 5321.from address but have the customer sign with DKIM. = In many cases, DKIM signing is actually free, whereas making the SPF = align is a paid service.=20 >=20 >> p=3Dnone >> Minimum expected implementation at pct=3D100: =20 >> All first-party direct messages (RFC5321.Mail=46rom domain =3D = RFC5322.=46rom domain) are verifiable using SPF, but may not have a DKIM = signature. >> Third-party direct messages ( RFC5321.Mail=46rom domain =3D = RFC5322.=46rom domain ) may or may not have DKIM signatures. >> Consequently, indirect messages are often not verifiable using DMARC. >=20 >> p=3Dquarantine >> Minimum expected implementation at pct=3D100: =20 >> All first-party direct messages (RFC5321.Mail=46rom domain =3D = RFC5322.=46rom domain) are verifiable using SPF, but may not have a DKIM = signature. >> Third-party direct messages ( RFC5321.Mail=46rom domain =3D = RFC5322.=46rom domain ) are verifiable using DKIM signatures. >> Consequently, indirect messages may or may not be verifiable, = depending whether the forwarded message included a signature. >>=20 >> p=3Dreject >> Minimum expected implementation at pct=3D100: =20 >> All first-party direct messages (RFC5321.Mail=46rom domain matches = RFC5322.=46rom domain) are verifiable using SPF and DKIM. >> Third-party direct messages ( RFC5321.Mail=46rom domain does not = match RFC5322.=46rom domain ) are verifiable using DKIM signatures. >> Indirect messages which are not modified in transit are verifiable = using DKIM signatures. >> Indirect messages which are modified in transit are outside the scope = of DMARC and must be evaluated by other criteria available to the = recipient system. >>=20 >> Having defined the policies/categories in these terms, the logical = next step would be a best practices document which discusses how an = evaluator might distinguish between direct messages, indirect unmodified = messages, and indirect modified messages. ARC obviously plays a role = in making these distinctions easier to determine and less error-prone. >>=20 >> Doug Foster >> =20 >>=20 >> On Sat, Dec 12, 2020 at 1:42 PM Dave Crocker > wrote: >> On 12/11/2020 9:37 AM, John Levine wrote: >> > In article <1AC986FF-507B-4917-9C6D-D84E9337FC7A@wordtothewise.com = > you = write: >> > aligned is not authorized by the domain owner and may be discarded = or rejected by the recipient. >> > Naah. >> > >> > p=3Dreject: all mail sent from this domain should be aligned in a = DMARC >> > compliant way. We believe that unaligned mail is from unauthorized >> > senders so we ask receivers to reject it, even though that might = mean >> > some of our authorized senders' mail is rejected too. >>=20 >>=20 >> As soon as this specification text, here, contains language about how=20= >> this information is to be used, should be used, or could be used, it=20= >> crosses over into creating confusion about expectations of receiver=20= >> handling. >>=20 >> It encourages misguided language such as the receiver 'overriding'=20 >> sender policy. The sender has no policies about receiver behavior,=20= >> because there is no relationship between them. Using milder language=20= >> here doesn't help, because readers typically do not read like legal = or=20 >> technical scholars. >>=20 >> DMARC provides information, not direction. >>=20 >> The spec already contains misguided perspective by talking about=20 >> 'policy' records and, even worse, "policy enforcement = considerations". >>=20 >> If the document must contain language about receiver choices in = message=20 >> disposition, move it to an overtly non-normative discussion section = that=20 >> legitimately covers a wide range of things that receivers do or don't = do=20 >> (cast as things they might or might not do.) And make sure none of = the=20 >> language hints at sender 'policy', overrides, or the like. >>=20 >>=20 >> d/ >>=20 >> --=20 >> Dave Crocker >> dcrocker@gmail.com >> 408.329.0791 >>=20 >> Volunteer, Silicon Valley Chapter >> American Red Cross >> dave.crocker2@redcross.org >>=20 >> _______________________________________________ >> dmarc mailing list >> dmarc@ietf.org >> https://www.ietf.org/mailman/listinfo/dmarc = >> _______________________________________________ >> dmarc mailing list >> dmarc@ietf.org >> https://www.ietf.org/mailman/listinfo/dmarc = >=20 > --=20 > Having an Email Crisis? We can help! 800 823-9674=20 >=20 > Laura Atkins > Word to the Wise > laura@wordtothewise.com > (650) 437-0741 =09 >=20 > Email Delivery Blog: https://wordtothewise.com/blog = =09 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc = > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc --=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=_5FC61C73-60FA-4C02-AD14-F6CA0DE17897 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On 14 Dec 2020, at 15:11, Douglas Foster <dougfoster.emailstandards@gmail.com> wrote:

I called that a third-party message, since the = RFC5321.Mail=46rom domain is different from the RFC5322.=46rom = domain.

No, you = didn=E2=80=99t.

Third-party direct = messages ( RFC5321.Mail=46rom domain =3D RFC5322.=46rom domain = )

I think =E2=80=98first party=E2=80=99= and =E2=80=99third-party=E2=80=99 are problematic definitions in any = case and I=E2=80=99m not sure I understand what your goal is here. Who = are you considering =E2=80=98party=E2=80=99?

laura

I = am open to revisions of how the boundaries should be defined, but as I = said in my reply just now to Michael Hammer, we need to define those = boundaries in a way that both sender and receiver understand.  This = is the full problem description:

We have these three types of = senders:
- first-party = senders

- third-party senders
- = spoofers

We = have these four verification states at initial transmission:
- none
- spf only
- = dkim only
- spf and dkim

We have these 9 routing = scenarios:
- direct (1)
- = indirect (8)
    with and without SMTP = rewrite
    with and without FROM = rewrite
    with and without content = modifications

Upon receipt, we have these verification states:
- Not verified
- SPF only
- DKIM only
- SPF and DKIM

For messages that do not = verify, the evaluator uses sender policy (none, quarantine, reject) to = categorize the message as either "verifiably spoofed" or = "uncertain".   What is the algorithm for doing so?

DF


On Mon, Dec = 14, 2020 at 5:05 AM Laura Atkins <laura@wordtothewise.com> wrote:


On 13 = Dec 2020, at 21:44, Douglas Foster <dougfoster.emailstandards@gmail.com> wrote:

Based on this = discussion, it seems evident that p=3Dreject should include language = about in-transit modifications which are outside the control of the = source domain, and consequently outside the ability of DMARC to guide = recipients.    Extending from that, I thought it would be = helpful to specify some shared assumptions between sender and evaluator = to make the interpretation of the settings less subjective.  =  I call this the "Minimum expected implementation at = pct=3D100".

What about messages which do not have = SPF verification but do have DKIM verification? A significant number of = email platforms use their own domains in the 5321.from address but have = the customer sign with DKIM. In many cases, DKIM signing is actually = free, whereas making the SPF align is a paid service. 

p=3Dnone
Minimum expected implementation at pct=3D100:  =   
All first-party direct messages = (RFC5321.Mail=46rom domain =3D RFC5322.=46rom domain) are verifiable = using SPF, but may not have a DKIM signature.
Third-party direct messages ( RFC5321.Mail=46rom domain =3D RFC5322.=46rom domain ) may or may not = have DKIM signatures.
Consequently, indirect = messages are often not verifiable using = DMARC.

p=3Dquarantine
Minimum expected implementation at pct=3D100:  =   
All first-party direct messages = (RFC5321.Mail=46rom domain =3D RFC5322.=46rom domain) are verifiable = using SPF, but may not have a DKIM signature.
Third-party direct messages ( RFC5321.Mail=46rom domain =3D RFC5322.=46rom domain ) are verifiable = using DKIM signatures.
Consequently, indirect = messages may or may not be verifiable, depending whether the forwarded = message included a signature.

p=3Dreject
Minimum expected implementation at pct=3D100:  =   
All first-party direct messages = (RFC5321.Mail=46rom domain matches RFC5322.=46rom domain) are verifiable = using SPF and DKIM.
Third-party direct messages ( RFC5321.Mail=46rom domain does not match RFC5322.=46rom domain ) are = verifiable using DKIM signatures.
Indirect messages = which are not modified in transit are verifiable using DKIM = signatures.
Indirect messages which are modified in = transit are outside the scope of DMARC and must be evaluated by other = criteria available to the recipient system.

Having defined the policies/categories = in these terms, the logical next step would be a best practices document = which discusses how an evaluator might distinguish between direct = messages, indirect unmodified messages, and indirect modified = messages.   ARC obviously plays a role in making these = distinctions easier to determine and less error-prone.

Doug Foster
 

On Sat, Dec 12, 2020 at 1:42 PM Dave Crocker <dcrocker@gmail.com> wrote:
On 12/11/2020 9:37 AM, John Levine = wrote:
> In article <1AC986FF-507B-4917-9C6D-D84E9337FC7A@wordtothewise.com> = you write:
> aligned is not authorized by the domain owner and may be discarded = or rejected by the recipient.
> Naah.
>
> p=3Dreject: all mail sent from this domain should be aligned in a = DMARC
> compliant way. We believe that unaligned mail is from = unauthorized
> senders so we ask receivers to reject it, even though that might = mean
> some of our authorized senders' mail is rejected too.


As soon as this specification text, here, contains language about how =
this information is to be used, should be used, or could be used, it
crosses over into creating confusion about expectations of receiver
handling.

It encourages misguided language such as the receiver 'overriding'
sender policy.  The sender has no policies about receiver behavior, =
because there is no relationship between them. Using milder language
here doesn't help, because readers typically do not read like legal or =
technical scholars.

DMARC provides information, not direction.

The spec already contains misguided perspective by talking about
'policy' records and, even worse, "policy enforcement = considerations".

If the document must contain language about receiver choices in message =
disposition, move it to an overtly non-normative discussion section that =
legitimately covers a wide range of things that receivers do or don't do =
(cast as things they might or might not do.)  And make sure none of = the
language hints at sender 'policy', overrides, or the like.


d/

--
Dave Crocker
dcrocker@gmail.com
408.329.0791

Volunteer, Silicon Valley Chapter
American Red Cross
dave.crocker2@redcross.org

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

-- 
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 =







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

-- 
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=_5FC61C73-60FA-4C02-AD14-F6CA0DE17897-- From nobody Mon Dec 14 07:37: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 AB3CC3A0EBC for ; Mon, 14 Dec 2020 07:37:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.2 X-Spam-Level: X-Spam-Status: No, score=-0.2 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lqr0U04JPEaF for ; Mon, 14 Dec 2020 07:37:10 -0800 (PST) Received: from mx0a-00143702.pphosted.com (mx0a-00143702.pphosted.com [148.163.145.77]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A46AE3A0EB2 for ; Mon, 14 Dec 2020 07:37:08 -0800 (PST) Received: from pps.filterd (m0156891.ppops.net [127.0.0.1]) by mx0a-00143702.pphosted.com (8.16.0.43/8.16.0.43) with SMTP id 0BEFQZFa019529 for ; Mon, 14 Dec 2020 10:37:08 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.com; h=from : to : subject : date : message-id : content-type : content-transfer-encoding : mime-version; s=20190412; bh=yiOrYOIdvq248i9K4CxmnCY0166Q2fee5siYQ3U2skE=; b=PCSVLGW4hbfdT3OkG8gSvKKDja3iGS71TGfYAKceHC+dhDYrfOlHjN6pXWVL4NzUzYTS IApODva/4/HgFkYhGS3NUnNPeLOUlN0WeNbZk/zOm0s58RlgH9vhbfDHuH8DTe9HREdM TYi9bJakWUlBcaqIAu46cfwS/wUyrGuUkNIfLkiQebaLFmw6dhHgy0EHn4fwc+5zJvIr jysRaFHGPdrUlszTxlVHehlm/6TWJWF/XvKI7RSqDZU3QVlr5KViP8aeb/OuFgIgTV+o knefNACfBM8UZjet4K3nOi5estKhHrG1AGsvMPCwYGG1By0UF4miiKmV249AQW2xM2GD tw== Received: from pacdcex53.cable.comcast.com (dlppfpt-wc-1p.slb.comcast.com [96.99.226.136]) by mx0a-00143702.pphosted.com with ESMTP id 35cujyj4sk-2 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for ; Mon, 14 Dec 2020 10:37:08 -0500 Received: from PACDCEX49.cable.comcast.com (24.40.2.148) by PACDCEX53.cable.comcast.com (24.40.2.152) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 14 Dec 2020 10:37:05 -0500 Received: from PACDCEXEDGE01.cable.comcast.com (76.96.78.71) by PACDCEX49.cable.comcast.com (24.40.2.148) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Mon, 14 Dec 2020 10:37:05 -0500 Received: from NAM04-BN8-obe.outbound.protection.outlook.com (104.47.74.49) by webmail.comcast.com (76.96.78.71) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 14 Dec 2020 10:36:48 -0500 Received: from MN2PR11MB4351.namprd11.prod.outlook.com (2603:10b6:208:193::31) by MN2PR11MB4582.namprd11.prod.outlook.com (2603:10b6:208:265::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3654.12; Mon, 14 Dec 2020 15:35:08 +0000 Received: from MN2PR11MB4351.namprd11.prod.outlook.com ([fe80::7ca6:b482:a6b0:4d42]) by MN2PR11MB4351.namprd11.prod.outlook.com ([fe80::7ca6:b482:a6b0:4d42%7]) with mapi id 15.20.3654.025; Mon, 14 Dec 2020 15:35:08 +0000 From: "Brotman, Alex" To: "dmarc@ietf.org" Thread-Topic: Multiple SPF in a single auth_results Thread-Index: AdbSLmBYY7jb/yr3SZKYcEKgpe4Epg== Date: Mon, 14 Dec 2020 15:35:07 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=comcast.com; x-originating-ip: [2601:43:101:380:976:eb21:7694:c750] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 52f4b72c-a52f-44c4-9416-08d8a045d63f x-ms-traffictypediagnostic: MN2PR11MB4582: 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: YzbjxUWhwCyj4jXEuCmyrEYIehmxCzqEAozNT/A/wYjY2JrzolViJuxAM4MaFLpuWfjSzpb57Tit14WXnM6y0MyYwHd6CZHskWeRmeX76vzhZY0VKsxMgLC2pk7PrtQ/7zLP2xh1e2vPHa3N3mJ2P+3mET4Vsz/RHcp/IS4KYaSXCnXAabtiLYUETkwU5wveNX/L5e7ZELQk/+b8ahDlIxnMWbhWQ8NuORLj/1syuCoqUqiwDcU7R8Ef0YG38GDYJEakqWdObdmjT0M3FoUsaHUZ6XT1ClTxG0SK6aPkU2hMMiHX6zAa1oO0DG9is2lRYkK4eOuu1avu1sFA3a8bGtOF4WIQf7wdoZWep39fcC4koitJ414+M6fBaESwyyo1TdWa4p6NYC02B+lHkprO9Q== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR11MB4351.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(376002)(136003)(346002)(9686003)(64756008)(186003)(66476007)(6506007)(71200400001)(86362001)(66556008)(66446008)(6916009)(8936002)(7696005)(966005)(8676002)(76116006)(508600001)(55016002)(33656002)(52536014)(5660300002)(2906002)(66946007)(4744005); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: =?us-ascii?Q?i26iSJNvXKYwMnpu8nnpw8YypPVMAxpHBIw6KVebhwYehpdTR2gXLIskZs8Z?= =?us-ascii?Q?p0m+8bcso5rkaP8Y1HdJM9Yrcbyzf3y4UynUIkAP6zB6rko/WIsFFgfiwyZO?= =?us-ascii?Q?2cOHgFEcUrdbuunHSh9ghTo9tAtiN1837fnQ2v8Ok78s1g4h13/MvZVrVnQ5?= =?us-ascii?Q?xGGoMVUBkxytcymU0N2PC6MTMJRNsO5ecDLa5OzxzlP2Cgy7jxURee7rrqUi?= =?us-ascii?Q?byxBHZblUXZwnrH1WLmN+FQiNEA5Twq9S4Bmug3QBHjlpotTEAea+JJ9U60N?= =?us-ascii?Q?2HULon44J2jPfcnkbgNrzTPqzLUcKgzBzXp3f+wEaCIajlBoCvEC/m6TZBts?= =?us-ascii?Q?UwTmx+AwUUtgz8IP/j+LGQY0mpg3oiIvRoCnteEnabEXb+cYAj3UHYyR6YmS?= =?us-ascii?Q?+HkBU2K5fOO1pz7G/wlRL2onaxMTkU0DR2X4T7I8LHNyU6skkRLU2Dg32me5?= =?us-ascii?Q?xwKmrJuly8sfMGRjS1cYqDQbZkbCNMvjGo2tp23Sr6b42/hG0RoUUovU1SFb?= =?us-ascii?Q?39HmtRNw3G2Wvb3YpKm82aWm6ZxlNhe9O2bP9+rn8SyLskMC9MSEAhwiyDzT?= =?us-ascii?Q?f1eWC94T8GqZE1WNjyDHzJksdeOLGTpcYXzx0bXLPZA48yhMyLCJG+xbdmWG?= =?us-ascii?Q?dMy55ZlKKykzbZwavDCtHO+amYUIYqqdCTJEI0PgbnTg0w86yg4LcVitF/1v?= =?us-ascii?Q?6FQMTenVxotoIq7OO4g01y3wVdeB7TqRjHOZOhcWrV2cGbGZefaEeB0UaFUA?= =?us-ascii?Q?hrt3uhyUVsGJUGDch4jxWv9PcY35Xng8VVznzV9sMrhB87ZxmyPTf/MeQlLx?= =?us-ascii?Q?t+QRRL4GPjzqZr4GLlR3NT+Q+a0sTazckirBccakoyTGcibj+ffk4y1EShbH?= =?us-ascii?Q?7OPAEhQy2t9wmOQIIJRrefpSbDh5FGyEwBJj3KWi1VHJapzJ84/m5uWDPRB2?= =?us-ascii?Q?qpAnkJoE9Eb0zXIHy4B9POjsQhbT4Pf3vUY1ZFDWUxgTIKjKtwrax6sGAbpo?= =?us-ascii?Q?XMF2h3/Rmh9t+bGGN9JFvhmtou2ZWQYGKTEKEORYb+6oHnY=3D?= x-ms-exchange-transport-forked: True arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=mJguJgRWeElVr6IBNWCnoOFgYwvm8faZ1BZskDCMafKnfcCUm8c1a7Gfkuof5dH6f9DX0+JIIWGzxeRq74gsJwzBRS3+JzEN6YRALwPjk/+HZaa9/8pzTMBXPok/J0ceg5PmGHFol7D439LV2oHcNxFg9rRNc3c5BP4Wo/j8xuTe1/iV/MG67ZhykLlXoKARsNaTnCr8jsRQCFWMyoBhn58dBYPVGH4/GFD7Gtd02nJeTQ2lwi1yBRyGe8ORhMCQpE8YeC5N17LHlWM1wjx2ue6/VM1bXhUQqpbIB43FPbsKdMEJx0cj2pEn+cU+TdN9FT/qPj9dJCdkFjOAOsEElA== 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=Xg3IcsxuyYLD8rNXZ0HXKoCduJZ503cgy0ZAMnS3JaY=; b=jo01eQn+QxNgciGB2XiHT7TVBmD7JPyF3Q1+ew6URUklGJiLLdDhWXew3CVD/iJwlfZRzvyY/0+G0rgJhqvsEa1aNRt25MUCZsoM5rSpoeyN1OGLQSvzzvaszJL7YgFf24LFjRG3AHw140qv2aYGqCxuQHQJasSifiItvl1fC43AO3Uw5LqETTSz4mwE2PJnR9WfyRv7R2oDlTXJEuxJUdSy39/9SHb1nlKfBBdhwLlSTNyWID66BN/lhoSK0659u8AO/wnzKZoHd16xOqtdVgx2xfGjXrmjMAHEiIDaMelXjO+j81QMT7FvSvLiLNeYDlEQ/LvKp5OtfeQoZwHPCg== arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=comcast.com; dmarc=pass action=none header.from=comcast.com; dkim=pass header.d=comcast.com; arc=none x-ms-exchange-crosstenant-authas: Internal x-ms-exchange-crosstenant-authsource: MN2PR11MB4351.namprd11.prod.outlook.com x-ms-exchange-crosstenant-network-message-id: 52f4b72c-a52f-44c4-9416-08d8a045d63f x-ms-exchange-crosstenant-originalarrivaltime: 14 Dec 2020 15:35:07.9254 (UTC) x-ms-exchange-crosstenant-fromentityheader: Hosted x-ms-exchange-crosstenant-id: 906aefe9-76a7-4f65-b82d-5ec20775d5aa x-ms-exchange-crosstenant-mailboxtype: HOSTED x-ms-exchange-crosstenant-userprincipalname: 0HDl8Dtxw9HZEUaxUqYVrky8sO7g/9jalxW7zTrYiyPPYZSb38ibpDWoyWwh0xfallmD4ZdlNns7azfpWnsTJqqB3nrO58j6ErHo/OxwvXc= x-ms-exchange-transport-crosstenantheadersstamped: MN2PR11MB4582 x-originatororg: comcast.com Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Forward AAETWQ X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.343, 18.0.737 definitions=2020-12-14_06:2020-12-11, 2020-12-14 signatures=0 X-Proofpoint-Spam-Reason: safe Archived-At: Subject: [dmarc-ietf] Multiple SPF in a single auth_results X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 14 Dec 2020 15:37:13 -0000 I'm seeing a report where the XML contains two SPF records within a single = auth_results entity. This doesn't seem correct. I found this thread: http= ://lists.dmarc.org/pipermail/dmarc-discuss/2016-April/003474.html and it sa= ys it's a bug, though, I'm a bit surprised (guess I probably shouldn't be) = that this is still happening. Is there some part of the RFC that makes thi= s appear like it's a legitimate report that could be misconstrued? Is this= something that should perhaps be clarified? email.peacocktv.com pass bounce.email.peacocktv.com pass mta-218-134.sparkpostmail.com. none Thanks -- Alex Brotman Sr. Engineer, Anti-Abuse & Messaging Policy Comcast From nobody Mon Dec 14 07:58: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 BB2AC3A0E27 for ; Mon, 14 Dec 2020 07:58:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.2 X-Spam-Level: X-Spam-Status: No, score=-0.2 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vdtw8MLEuTFp for ; Mon, 14 Dec 2020 07:58:04 -0800 (PST) Received: from mx0b-00143702.pphosted.com (mx0b-00143702.pphosted.com [148.163.141.77]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DFEB33A110C for ; Mon, 14 Dec 2020 07:58:03 -0800 (PST) Received: from pps.filterd (m0184890.ppops.net [127.0.0.1]) by mx0b-00143702.pphosted.com (8.16.0.43/8.16.0.43) with SMTP id 0BEFuVDj011151; Mon, 14 Dec 2020 10:58:03 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=20190412; bh=9dJpzgHD7PyrXOmXDnOoEZXUIKGcbZ0eGYRzUHIszfM=; b=N5AUXGCAhe1GnbO3C4apMitlmWUXSGT7gB9fJBgkeWL3Zi06yOExd5xXUkG5ngMC9E/G x0WCo9BDfATBbYC3jmgGkFUn0xZCEd0U6MH++/dKJRBERinP3B6kh4i3JHcAlZLTPHhT 5myqWXbikhn9AJOK1WP1+9rOeG66sow3HhEOVWP6eA/wikdITyekJnqf5cj78LzgUcgg 2YHLvhqtxsVsAaoIIO9LtNovNuzy1gdNuZkXqNiS3mE9bv+0p4sBmgHSgusY8DN/l9m/ vF/VG2jbsCIHFAkQ4hKSx+yT8o5q1TOCJrUJ+BfHYrsIX3uYFOPDs9IAn0bfrUPACrqD vA== Received: from pacdcex55.cable.comcast.com (dlppfpt-wc-1p.slb.comcast.com [96.99.226.136]) by mx0b-00143702.pphosted.com with ESMTP id 35ctukt0pw-2 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 14 Dec 2020 10:58:02 -0500 Received: from PACDCEX49.cable.comcast.com (24.40.2.148) by PACDCEX55.cable.comcast.com (24.40.2.154) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 14 Dec 2020 10:58:00 -0500 Received: from PACDCEXEDGE01.cable.comcast.com (76.96.78.71) by PACDCEX49.cable.comcast.com (24.40.2.148) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Mon, 14 Dec 2020 10:58:00 -0500 Received: from NAM12-DM6-obe.outbound.protection.outlook.com (104.47.59.176) by webmail.comcast.com (76.96.78.71) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 14 Dec 2020 10:57:55 -0500 Received: from MN2PR11MB4351.namprd11.prod.outlook.com (2603:10b6:208:193::31) by MN2PR11MB4320.namprd11.prod.outlook.com (2603:10b6:208:195::32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3654.12; Mon, 14 Dec 2020 15:57:53 +0000 Received: from MN2PR11MB4351.namprd11.prod.outlook.com ([fe80::7ca6:b482:a6b0:4d42]) by MN2PR11MB4351.namprd11.prod.outlook.com ([fe80::7ca6:b482:a6b0:4d42%7]) with mapi id 15.20.3654.025; Mon, 14 Dec 2020 15:57:53 +0000 From: "Brotman, Alex" To: John R Levine , "dmarc@ietf.org" Thread-Topic: [EXTERNAL] Re: [dmarc-ietf] Clarification of Subdomain Reporting Thread-Index: AdbP572VQsVJ89zAQIeNUCxVu9wIqgADX68AAAOUqhAAAHThAACKl8og Date: Mon, 14 Dec 2020 15:57:53 +0000 Message-ID: References: <20201211193845.63466297AE5D@ary.qy> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: taugh.com; dkim=none (message not signed) header.d=none;taugh.com; dmarc=none action=none header.from=comcast.com; x-originating-ip: [2601:43:101:380:976:eb21:7694:c750] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 46f8126e-914d-4cb9-c809-08d8a049043f x-ms-traffictypediagnostic: MN2PR11MB4320: 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: psuRNuGiHMqrQgQfR1FdFDoPcOzSQnRJ95YDY9+lH3epShjJum3oc6TuStmXhFPvP63d625EwJFoX2r03GWt/LeF+5YOFv8C1kuuQwt+Tz77TlF8sTcMo2dCdvZT8Fg4kPxOBJCLt25a8xvU8xnbGbHqSw9q1U9YrIwoTL4/TzvlvuTGTezGIG90T1a74/vY7690QPUhCZyFQnJ4VomY4soX6ij9hS/QhHRLN1Ma+mF8U/sncYWFLKxJm4aXGBwsCQvxOxOYzIhQcgHpYtgyK6YCGDF2FdMoNk/KA6RX4HB3d54cGuhs7pe4LPCQw2623vHgLPEovFMUVMPq6NfW22gBgW8XWxh7katJfFWLF/auJF+QVuq2HjHYNU0U2O+Cv1kU8D4cf2N0hoBq1sbXZ9vxn4wobTDRNT4rQKQm4G2TueAq8O/joeVpeuT7HNThrViXvIs9xiRECtMzIZaFNA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR11MB4351.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(376002)(346002)(136003)(366004)(33656002)(52536014)(55016002)(64756008)(66446008)(508600001)(83380400001)(966005)(66946007)(66476007)(66556008)(2906002)(110136005)(71200400001)(5660300002)(83080400002)(6506007)(53546011)(86362001)(7696005)(8936002)(8676002)(76116006)(9686003)(186003); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: =?us-ascii?Q?v9mF0taxgMPc9t4SDGLuYIo/URZnggC/GJ7yzxVJeIQO2qAjpDlUsi8jv50x?= =?us-ascii?Q?J+Vt+2WdHB6WmalaYUEttWirorP6GpJAcq86J52pT6fm7T9uudkGktcoKCYV?= =?us-ascii?Q?ShaKVTEpRlMQc4+y+DKRMsUSJ+HgFQGrWyZMqlDI266priDsaT9l2UySEonH?= =?us-ascii?Q?ta+T0kKdsfXwUa8ffhp8TMh88FoAYgJTDFo0g9BigzUnnm4aSJ7HV95jEz4l?= =?us-ascii?Q?/901bCgtXGckGgvTt7wqudINMvG23VfTF4lPrW/0eGodQ3702BDUyuafpCDx?= =?us-ascii?Q?xuOBAyRYBUEEml9O7j5ynTJvPUz+Fqx5hMtUJwd5bW7+reKTagY+Nobxyoaz?= =?us-ascii?Q?9219eHbr1aBEkd43vljroMDi4MYrOjZxi7/HyyI1h3ra0FiJI5y1yTPkjSlg?= =?us-ascii?Q?MX+J3Pd5btVgmRRy12oNtePd1uBlMk3ROIDUYEL8x6nbuTBob8v+Auq9drHS?= =?us-ascii?Q?bpG6Iqx1SZ7UW3zJUKCPnA0Kw6dD8VY7BlAdcOvepPpPS2ukkBU7k9nP2Eas?= =?us-ascii?Q?gBHoClU0E2lyT6jN2g/oOlR1CTDJtvoAP8Do09yshB/LPowT0z8cHA+R35c3?= =?us-ascii?Q?Es69/MdPQ/+GRMQ42Vio/5BT79VJHfhf5RF8lALU9TPlORy2zk5MW/NqNNkl?= =?us-ascii?Q?OsoWq5l/f7qbEMInUpfcOq/fbtIkUvCB1EiAM1w6RUjG0QjwKVYKYn0Zu7Hi?= =?us-ascii?Q?iHR5lL/P3WlDv1QLPqvHGK7JIPwtPnLIR9P+QDPVPmZ3UvQRa/eLNUrG+g2p?= =?us-ascii?Q?ok0HQY57Jja82KbzcmKh9IPE/HeKwN9TpRSFKpmjhlE6PAdjvm3x2Zxve2rL?= =?us-ascii?Q?XbV8don3yJNVCv84bHp5lUJSZglXkTSTH8PDkWBQiHvLGKQVXisON5c9BoFR?= =?us-ascii?Q?6VU3bj0XTxSZwbGckSWSdWqHlhblxeuvAJofEnGmeX1FO0NwtXfIyBb44ncv?= =?us-ascii?Q?Pgbrj0ipPlKvSG5ZQFIedqnfkBWIOK20am4Q0DxZVHSIhfbScQ/nxhVhn8py?= =?us-ascii?Q?dj3MkjDqaaWFG9y67KliEPpSKrCtSFCcSske3o1s7wc3YCQ=3D?= x-ms-exchange-transport-forked: True arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=OsTflYIonNrprnzBt8Tiel/n/AnljI2lSeWA3ORyBZZLQpOTb9rA4GYeQeYG1XgG0fCSGcaWI3mfuDVChrsd4qOLBMj/WhQxVpSzatz+6Tj3WlwKolQKSRy8dvHP0vcOfMXmO+DE+fYXmp65JZCR2rGH3a6+z0geXXSlEszFNHAivwLzgQqdPF+fUUBBCPt7qR7L3Rs0tE4lh+3E6gWfs3LvP/TBoC+3JZ1kWOnI3NwB74F2PO6SLQmoqjkb+HSq581JCriuKDPFxXczvOrBvZWeym34UNrCjVf2pEVOS3JVBHUycy1p/Db/5oq5RTGTKH35OsUSi/cNfwjxcT3MPg== 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=yQmBhaVLSrIiKkW9VdJNQO1tVZLN55ElzUaifnmcrzo=; b=QhJ7bY/JU8+f7W0/ql09iYs0i10A5ynnn/rW1upxunva0ff8FmfxYjFAVBqcmk59fCji0Vfut92gRHurxYlHL351qqgXK6iVRrwxs4oa21nwPEK2SQrhsvrjFw6Tj9K+Q8kLm6KTwYv3WwM1t+mF91CH6zGJABHlkQquyASvqzBKISDBn7gVhkgpm7A13moaFY5RC1gpr5RH/2rsDZZyCK2yT3SuaUIeEmU8dqbxevsFesCqyW1b4oHlF07851Febt+m7vQDKLDDKLDTwpa6FRvj8cyCK4zyiLGygjSZ8655TJqqYOW8miXUPtaLR6vZAnhIK0o40u9uC5igsBIdsQ== arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=comcast.com; dmarc=pass action=none header.from=comcast.com; dkim=pass header.d=comcast.com; arc=none x-ms-exchange-crosstenant-authas: Internal x-ms-exchange-crosstenant-authsource: MN2PR11MB4351.namprd11.prod.outlook.com x-ms-exchange-crosstenant-network-message-id: 46f8126e-914d-4cb9-c809-08d8a049043f x-ms-exchange-crosstenant-originalarrivaltime: 14 Dec 2020 15:57:53.6361 (UTC) x-ms-exchange-crosstenant-fromentityheader: Hosted x-ms-exchange-crosstenant-id: 906aefe9-76a7-4f65-b82d-5ec20775d5aa x-ms-exchange-crosstenant-mailboxtype: HOSTED x-ms-exchange-crosstenant-userprincipalname: eMvtOZoSDPz55Ch7/XRw3xDCUCdh5Bkkit+Y7AGfSArHEDo9WmVzuxegbtREZVLvc2g9s3ZGmCjM/k01QKfdMO9LQ+fdA1E7uKACHWaKYTE= x-ms-exchange-transport-crosstenantheadersstamped: MN2PR11MB4320 x-originatororg: comcast.com Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Forward AAETWS X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.343, 18.0.737 definitions=2020-12-14_06:2020-12-11, 2020-12-14 signatures=0 X-Proofpoint-Spam-Reason: safe Archived-At: Subject: Re: [dmarc-ietf] [EXTERNAL] Re: Clarification of Subdomain Reporting X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 14 Dec 2020 15:58:06 -0000 -- Alex Brotman Sr. Engineer, Anti-Abuse & Messaging Policy Comcast > -----Original Message----- > From: John R Levine > Sent: Friday, December 11, 2020 4:34 PM > To: Brotman, Alex ; dmarc@ietf.org > Subject: RE: [EXTERNAL] Re: [dmarc-ietf] Clarification of Subdomain > Reporting > > On Fri, 11 Dec 2020, Brotman, Alex wrote: > >> That's a somewhat incompatible change, so I'd want to be sure we > >> agree that it's a real problem that's worth changing the report > >> format. I suppose if we do we should encourage report consumers to be > prepared for old and new formats. > > > > The goal was to clarify the language, without (to the best of our abili= ty) > changing the schema. I'd welcome a other attempts at clarifications (if = you > believe mine introduces structural XML changes). > > So it'd say yeah, we know the XML lets you put multiple header_from > domains in the same report row, but please don't do that, send a separate > report row for each header_from? > > I suppose that could work. So it should be clarified as such: o Data for each Domain Owner's subdomain separately from mail from the sender's Organizational Domain, even if there is no explicit subdomain policy Perhaps changed to something more like: o A separate report should be generated for each 5322.From subdomain, reg= ardless of which policy domain was used during receipt of messages For the other thread with Ale, is there anything wrong with stating both mi= nOccurs/maxOccurs set at "1" so that it's more clear that it must be once, = and only once? > > R's, > John > > >> > >> > >> > >> >> minOccurs=3D"0"/> > >> > >> >> minOccurs=3D"1"/> > >> Old: > >> > >> >> minOccurs=3D"1"/> > >> > >> New: > >> > >> > >> > >> > >> > > > > Regards, > John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY > Please consider the environment before reading this e-mail. > https://urldefense.com/v3/__https://jl.ly__;!!CQl3mcHX2A!UPJ_XPLNAqIcy > 2hcn14oeuebDZfD_i2QOE4Z0FhOoQemEIHEyov_kFTxybH4FE6WvlDw$ From nobody Mon Dec 14 08:10: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 8A4413A13DC for ; Mon, 14 Dec 2020 08:10:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.2 X-Spam-Level: X-Spam-Status: No, score=-0.2 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=henningkrause.eu header.b=SeXYZ+FR; dkim=pass (1024-bit key) header.d=henningkrause.eu header.b=yNZsQgbg; dkim=pass (1024-bit key) header.d=henningkrause.eu header.b=XC4eYSZ9 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VDGf9wXmyC68 for ; Mon, 14 Dec 2020 08:10:32 -0800 (PST) Received: from de-s01-gw2.mail.cloud.nospamproxy.com (de-s01-gw2.mail.cloud.nospamproxy.com [193.37.132.171]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 95E713A1372 for ; Mon, 14 Dec 2020 08:10:31 -0800 (PST) DKIM-Signature: v=1; c=relaxed/relaxed; d=henningkrause.eu; s=dkim1e; t=1607962227; bh=OtHHlK98IzpAbXkaRnrRJBA4TS3Dk9ldMbWvKD4ky+4=; h= "Subject:Subject:From:From:Date:Date:ReplyTo:ReplyTo:Cc:Cc:Message-Id:Message-Id"; a=ed25519-sha256; b= SeXYZ+FRLQ7bHJ4F3xEeXlRzpCy1E68t3jXxjskLbd+QHe8A912JjOq75HC5w1gINVyXcsyYnf1k1udRzxgMBQ== DKIM-Signature: v=1; c=relaxed/relaxed; d=henningkrause.eu; s=dkim1r; t=1607962227; bh=OtHHlK98IzpAbXkaRnrRJBA4TS3Dk9ldMbWvKD4ky+4=; h= "Subject:Subject:From:From:Date:Date:ReplyTo:ReplyTo:Cc:Cc:Message-Id:Message-Id"; a=rsa-sha256; b= yNZsQgbgxC9ZGJ+/reEzanF6oW7/Az7wWuwhEkt1j7PrcdzwIkIKEsBO4JZ9QNyHLMLs0dLfVAT+K0j+8cN9ACGlfnUnEbqM5rC8rHbdxndUtICdEFQYLtcjCla3B5EULE0aE02pWLtOTvkqKNmSSXPQMcNXCPrlChLENtZAEt4= ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=g9p/UT7F8y/8/Q8ifq9Q+YUnf6yxJWkFyM42KO9sz7iac5tvXbQfAsInBKX+f7LS84PUmtD/7E+GkhvbkcVfopjnQMnzRPdCYx1W4tfjHHm22riXGPtVeA0UfaXe5D18PUFxx40Vw9EADUOIl9cVkcfg24Nx8qgDEXhbbJdkC7hj16NIA1BhINNKnLKmcAokjs9cAiqjOIbYn6ZRleM6Jy4STrvCT2QHInZzePBbDuyoTEAbwpGzcj65Wwk7R9trZJWaiNGzrIw5IeqO1ml52yxqZ2pXMaP03j8bLcO5jrUvxgP/ltadqq0WTDdpIxzknEiYrTjGgJDVrMipn6aM+Q== 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=OtHHlK98IzpAbXkaRnrRJBA4TS3Dk9ldMbWvKD4ky+4=; b=OOZJF1X2hhZVBD/ohxM4CyregAx2UWmwD815gZLtwNOWdKhk3ZR2FKnilx3ujQ11cE+uJppaVAWjaaRyTwx47Fteyxc+aXCRVS89WIEFZFulam1xn6X8gEEWFxlAVPiypJAczV4zmhhnHTJQSxSaHXuCyyN3eH4nSOntfao7xzsLmRLATJsoX7m6fI7OXtpnMJ0r3stfAh6sFSOsBDxh5Jiq01F9ofPlzEKgSMxFw/RvX8pW1gH6Mfa0rcyjbT1zMYQzflMqSowfJkLJUZpnKTCzMl68TdSKCj1fJugwDHiY95PIyMMoxyWxCrVmnRXfYviLjx2uYfuKAa+lrkJEfw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=henningkrause.eu; dmarc=pass action=none header.from=henningkrause.eu; dkim=pass header.d=henningkrause.eu; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=henningkrause.eu; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=OtHHlK98IzpAbXkaRnrRJBA4TS3Dk9ldMbWvKD4ky+4=; b=XC4eYSZ9+FJK6WqE+N96mrjEt3C4L5JPAsvMYxE+3Z0QoVDTkWEZXwpDybXvBxE+xjUIxWS2h4ojUeN36Dgh57wU97XOfUkrGNOlSK1NhWjojCdSFdFRPr4WbuSH6nkCu0nRI5BNmd3o/uv6egREnNpvf6LuGVYH7DwA565+kZA= From: Henning Krause To: "Brotman, Alex" , "dmarc@ietf.org" Thread-Topic: Multiple SPF in a single auth_results Thread-Index: AdbSLmBYY7jb/yr3SZKYcEKgpe4EpgABSIhA Date: Mon, 14 Dec 2020 16:10:22 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US, de-DE 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=henningkrause.eu; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 5ffb7a24-748c-435c-cf98-08d8a04ac311 x-ms-traffictypediagnostic: DB8PR08MB5132: 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: Z8Q7VxWKPhYi4Zh5eJYXfVI2PG+5Hu+wU2r0tzPmS5FKK4Wbisi3CY+WC1r+zxFguxpISZj+FJJ5loCBD1PAFiHGfli5Rh4x4A8z48I6Hcx0Bfm6HKQLc4W8Pasg5iNebjkkBo7WNa8ObryD7m1B2AFu9RGblXh6rtXXK+UZnSzE+/svg6pRRHVMiryEccG9LDy+ra0O5yP93bpmMa6QewUKUAeVW2RvIgTqGU39hePzPFo7wlVkqrvqfgfhEh+L+d7IC9G89NGxJ5DMCNbLjGsIjld6ffu1oMsH5FvQscgWH0rQxmJl7PeIhki3l0iajRKBDEX9W5Bqs4UOo6JX6OlhfrcVptJO7fapNiM4Vem5T+C/t0neyXGhVwM/xhlGeBcUdFBrKXe1D1yN9JIQKA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB7PR08MB3498.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFS:(396003)(346002)(376002)(366004)(136003)(39830400003)(83380400001)(478600001)(33656002)(76116006)(86362001)(8936002)(6506007)(55016002)(316002)(9686003)(110136005)(66946007)(7696005)(71200400001)(52536014)(64756008)(66476007)(66446008)(966005)(66556008)(186003)(2906002)(53546011)(19627235002)(5660300002)(8676002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?us-ascii?Q?FRGzwBSOmsviGARzvEWFQYas+veXmvRlxvASsBas2vlQjZ4sY9CsPmX9+6XQ?= =?us-ascii?Q?Vw0iFkVo32epwNqyVApSwb5bHB/kMvLhHM9JQSa5ijB2N64O264UgT8Br3RL?= =?us-ascii?Q?UVLIpjAYOoiIazx+CJBeNtPcch6EUvhp7RGY4yabOyg2RotSsS2j0OWM4cCZ?= =?us-ascii?Q?la4NX76aW3qLvRr32MXsfk7nimOmEcRV/4pjhX5IiopOMlQKoK/NqOxD9Gkh?= =?us-ascii?Q?XuoEtKFDp3BXgIpae5Nz1fm60ngRyJKWBsZtzfq04c2+m0tS4nv+osxqmj7o?= =?us-ascii?Q?5ITXikFQLjxfKeuwFRYmHl5l7sNWIEjC82AV5RCWo0vw7MiDg0xYW3iDrLX3?= =?us-ascii?Q?elM9rWGUvHiyF6yOBewauS2WxqvsKKuvs62PU30b7v/ziFmKdd5AySHxQpcp?= =?us-ascii?Q?9zEej8BSQH/+kE1PDFXXtUzyB5+TyzSPbgOuhABKxU0aLYLlP64ZYe4q0EQd?= =?us-ascii?Q?0YW8RUkxsApwu/YuRhk2G/1OeN6mibb/+Qe3Sr+A10C8aoeugT34AakqwkMC?= =?us-ascii?Q?5pabSOnb3hjUjJcSYhx63twNP/7ekant2foLAtYJktpivwHM3uZ8pCpHpmrK?= =?us-ascii?Q?UmWDsTEcyrkjL2DrsaWnP88J+iCHiZ5kn6l2X40yETehzxxmwgu5BQM2MOKd?= =?us-ascii?Q?c4NCEnZjJKZ+z0xQD9P6WeT95o2p5c3mJfw5+64Pa9hDG4uYaJFBtB+zYqCD?= =?us-ascii?Q?/YB7SWJoBhD+jSvsIonQOz15erty4v8KBUwP6PY5PhvK0SjhSrz814c0pJBC?= =?us-ascii?Q?IwOZcrjlGt2jcZgrHqlxWdkvddM65io5Pjpvwm9ac+kjDxDj/QJjKGi9o/gY?= =?us-ascii?Q?tAG2/L4TpBe6B6Rg/mRTTuFGt5EJJZD+vKbdBrNtc9H/LtkL91XmeLRqwgPO?= =?us-ascii?Q?QN1uwTADgqEvNsRwv9UgErS36snotqMabZggLt6eKxJtlv7/tcDxCcmYCJAV?= =?us-ascii?Q?wk9znJBtBMbZ148kt60YkuaH6F+s7Mrl5nngFvkhDYkJcHHPO7whPguD17N8?= =?us-ascii?Q?YAQGS5lHG0dN62lBPSg3+kMkCJ/0voKzPkhf5FF2q+k/kUA=3D?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: henningkrause.eu X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DB7PR08MB3498.eurprd08.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 5ffb7a24-748c-435c-cf98-08d8a04ac311 X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Dec 2020 16:10:23.1724 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2041dc2d-8eaa-4f51-96a8-b4923f969cba X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 3BIoFLv9+qM335ZEqUSsOxONhNk/N9++C3zC8NLHUxLLRs3ykQDEA8pld+4qQRcwuyHU+ybffXVcAXIz1hx/Jw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB8PR08MB5132 Archived-At: Subject: Re: [dmarc-ietf] Multiple SPF in a single auth_results X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 14 Dec 2020 16:10:36 -0000 Perhaps the first one is for the mail-from-domain and the other is for the= EHLO host? Kind regards, Henning > -----Original Message----- > From: dmarc [mailto:dmarc-bounces@ietf.org] On Behalf Of Brotman, Alex > Sent: Montag, 14. Dezember 2020 16:35 > To: dmarc@ietf.org > Subject: [dmarc-ietf] Multiple SPF in a single auth_results >=20 > I'm seeing a report where the XML contains two SPF records within a singl= e > auth_results entity. This doesn't seem correct. I found this thread: > https://stack01.cloud.nospamproxy.com/link?id=3DBAgAAAAfpHeh4JGMq5wA > AABTUQz3QBhcskBhLXvN_sPByIkTUJ_191QbNMs1tjGZXePYW51PlsXJiHzgxa > 2k95gYKyEvascW0xCd7vkfXGIcW-SMik1X4yMySldQ- > qHoCA66NmA7TaPPuwEtF7ZPQYLlZqdD7I5R3KNSFh2RaMp6bqp2L8XhNLlAJK > uMYUKvKSh3RMIePwJj3aMWZVgoSUPgaHbNCkaiscGIUps1 and it says it's a > bug, though, I'm a bit surprised (guess I probably shouldn't be) that thi= s is still > happening. Is there some part of the RFC that makes this appear like it'= s a > legitimate report that could be misconstrued? Is this something that sho= uld > perhaps be clarified? >=20 > > > email.peacocktv.com > pass > > > bounce.email.peacocktv.com > pass > > > mta-218-134.sparkpostmail.com. > none > > >=20 > Thanks >=20 > -- > Alex Brotman > Sr. Engineer, Anti-Abuse & Messaging Policy Comcast >=20 > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc From nobody Mon Dec 14 08:12: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 7898F3A1255 for ; Mon, 14 Dec 2020 08:12:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[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 4WlccYM_d4oE for ; Mon, 14 Dec 2020 08:12:29 -0800 (PST) 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 76F2E3A1232 for ; Mon, 14 Dec 2020 08:12:29 -0800 (PST) Received: from [192.168.0.109] (c-24-130-62-181.hsd1.ca.comcast.net [24.130.62.181]) (authenticated bits=0) by simon.songbird.com (8.14.4/8.14.4/Debian-4.1ubuntu1.1) with ESMTP id 0BEGGFsu019185 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Mon, 14 Dec 2020 08:16:16 -0800 To: Michael Thomas , dmarc@ietf.org References: <20201211173722.6B4DF29782C7@ary.qy> Reply-To: dcrocker@bbiw.net From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: <52077ae3-0b6a-8532-d21d-4f5b51413ded@dcrocker.net> Date: Mon, 14 Dec 2020 08:12:23 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] p=quarantine X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 14 Dec 2020 16:12:30 -0000 On 12/12/2020 10:57 AM, Michael Thomas wrote: > As a developer for 40 years, I can safely say that reject or > discardable or whatever it was in ssp are all abundantly clear and > that nobody writing a filter would make the error that you keep > insisting that we would. An appeal to authority?  In this group?  Really? So that means that my citing 50 years of writing this kind of networking standard and seeing exactly the kinds of misinterpretation I'm expressing concern about carries more sway than your own experience (which I suspect is a lot less than 40 years of writing specifications for the public Internet, as to writing them for more constrained environments.) And the above is mostly meant to serve as a demonstration of just how inappropriate an appeal to authority is, here. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Mon Dec 14 09:01: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 8BB4E3A0AC1 for ; Mon, 14 Dec 2020 09:01:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[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 cMfepl7ndlWe for ; Mon, 14 Dec 2020 09:01:47 -0800 (PST) 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 9663D3A0ABB for ; Mon, 14 Dec 2020 09:01:47 -0800 (PST) Received: from [192.168.0.109] (c-24-130-62-181.hsd1.ca.comcast.net [24.130.62.181]) (authenticated bits=0) by simon.songbird.com (8.14.4/8.14.4/Debian-4.1ubuntu1.1) with ESMTP id 0BEH5YBM024831 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT) for ; Mon, 14 Dec 2020 09:05:34 -0800 References: <20201211173722.6B4DF29782C7@ary.qy> <6dc2d62e-e288-8d8f-44b2-6f42e7e580@taugh.com> To: IETF DMARC WG Reply-To: dcrocker@bbiw.net From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: <65c61813-0d8b-bff7-9f6c-6e01db119b86@dcrocker.net> Date: Mon, 14 Dec 2020 09:01:41 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] p=quarantine X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 14 Dec 2020 17:01:49 -0000 On 12/14/2020 7:31 AM, Laura Atkins wrote: > I am agnostic about moving the ‘what to do’ section. I think it makes > sense to keep the sender definitions and the ways receivers can > interpret those declarations close together. I'm pressing for clear separation because we've got an existing problem -- and DMARC isn't even close to the first case of this -- where people over-interpret the meaning of non-normative information. So, I think that 'close together', as in 'in the same document', is fine and even good.  I think that  as in 'in the same paragraph' or even 'in the same section' is not. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Mon Dec 14 10:00: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 727403A0D10 for ; Mon, 14 Dec 2020 10:00:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.15 X-Spam-Level: X-Spam-Status: No, score=0.15 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, 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=mtcc.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 KN3csVcps1Cl for ; Mon, 14 Dec 2020 10:00:40 -0800 (PST) Received: from mail-pl1-x631.google.com (mail-pl1-x631.google.com [IPv6:2607:f8b0:4864:20::631]) (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 420373A0B2D for ; Mon, 14 Dec 2020 10:00:40 -0800 (PST) Received: by mail-pl1-x631.google.com with SMTP id x12so8588488plr.10 for ; Mon, 14 Dec 2020 10:00:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mtcc.com; s=fluffulence; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=u2gcF28ATtkHMG8+gPBswQJj9LKVmjwMtpwPdvTTfjM=; b=fKt/nKaWnV+K6iP852mIFrpoAZrB5qUo8Y4x6YCYKq0MblfkyRUAmHXVBVYV2n41q9 19h4UgL7NZ7VXuXf5MPEd1P2BLENPG5/peKK4LHgK5noObhjArz6aag+4SX6ff/jKvvO H0hsk61lLbha6fcWCZlgnvUFpvFpRZiCuCi7hO0YQB28ecLnnKG8X9p4zAiftkF0BVao YC0LEhpX2rCyNrehRjUbkd/pYw2x3acMNhIkA5KJAW04DIt9vSQM9fEGitdmssqOAtJG nKRF2c45PIeRZdwMUN1MiprVy7pA+G2n8YAF9zmttdYrBeQmMtR//s0yuzlzrt+MCF0U GM0A== 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=u2gcF28ATtkHMG8+gPBswQJj9LKVmjwMtpwPdvTTfjM=; b=KvW1p6DpOAgXVs4xJNx5IAlsbGEKTCEufBD4Hdgsyfv/itR1ncxxVDL19VTx3ll54c MdgQC+lNRBt0/kQU8CXt+8b9BlCiEhE6JxEDGDrhEYyE/H2gixuZOkS2/fbzu3M7QbHm qCAeKKNIHWsjC9m45YQ5ps3px4U7YgIo1QrYbYJXzEw4Cd4Ybn28gRBy5YDLhHSt1gcH X+PV2mhr5qHdYY9BGzUH+kLxpS89LsTeaaLuuDiiEJnYanSk8PauPMql34TRMrh3Zm9U nDk/verH09NkoZF2SH8YBoc6Yn869aL4sWA66WEuebB8kE2ZWWiV/Qnjq7kG94X1GIV1 MwdA== X-Gm-Message-State: AOAM5317FA6fMM5ATyyy9gU1VXAk0SA2eaMFtRX66P7Bz791uTOFhlHr MzaMkOTPvuTTzbbyME7DygsluOJgZOx3LA== X-Google-Smtp-Source: ABdhPJw6736rKbTvZgoPqTLnuLIO6Sd8XK3I61Ik7J0xA86B6wU+f4Fl4MdvZcte/VCyBMqmdL8wkQ== X-Received: by 2002:a17:902:70cc:b029:da:ccb4:c266 with SMTP id l12-20020a17090270ccb02900daccb4c266mr23556838plt.37.1607968839093; Mon, 14 Dec 2020 10:00:39 -0800 (PST) Received: from mike-mac.lan ([206.107.197.128]) by smtp.gmail.com with ESMTPSA id gp14sm19023673pjb.6.2020.12.14.10.00.37 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 14 Dec 2020 10:00:38 -0800 (PST) To: dcrocker@bbiw.net, dmarc@ietf.org References: <20201211173722.6B4DF29782C7@ary.qy> <52077ae3-0b6a-8532-d21d-4f5b51413ded@dcrocker.net> From: Michael Thomas Message-ID: <4289adb4-4ea2-7e4a-2a33-37608fc2e86e@mtcc.com> Date: Mon, 14 Dec 2020 10:00:36 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 MIME-Version: 1.0 In-Reply-To: <52077ae3-0b6a-8532-d21d-4f5b51413ded@dcrocker.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] p=quarantine X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 14 Dec 2020 18:00:43 -0000 On 12/14/20 8:12 AM, Dave Crocker wrote: > On 12/12/2020 10:57 AM, Michael Thomas wrote: >> As a developer for 40 years, I can safely say that reject or >> discardable or whatever it was in ssp are all abundantly clear and >> that nobody writing a filter would make the error that you keep >> insisting that we would. > > An appeal to authority?  In this group?  Really? > > So that means that my citing 50 years of writing this kind of > networking standard and seeing exactly the kinds of misinterpretation > I'm expressing concern about carries more sway than your own > experience (which I suspect is a lot less than 40 years of writing > specifications for the public Internet, as to writing them for more > constrained environments.) > > And the above is mostly meant to serve as a demonstration of just how > inappropriate an appeal to authority is, here. > Yes. I and developers like me are the target audience, not you. When we tell you it's not a problem, you should listen to us rather than badger us and tell us you know better. You have wasted years litigating a non-problem, and continue to litigate conversational speech as if it were some gigantic problem that will never be solved unless the world over uses some never quite precise enough language. p=reject is completely clear what its meaning and intent are. This is a waste of time, and a major symptom of why IETF is considered sclerotic and to be avoided if possible. I started this thread about p=quarantine, not p=reject as the subject makes abundantly clear. If you want to relitigate p=reject, kindly create your own thread so I can more easily ignore it, and the chairs can rule as out of scope because there is no ticket. Mike From nobody Mon Dec 14 10: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 7574C3A0F04 for ; Mon, 14 Dec 2020 10:09:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[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 kTTCXmLw1m-G for ; Mon, 14 Dec 2020 10:09:16 -0800 (PST) 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 BD8E53A0F02 for ; Mon, 14 Dec 2020 10:09:16 -0800 (PST) Received: from [192.168.0.109] (c-24-130-62-181.hsd1.ca.comcast.net [24.130.62.181]) (authenticated bits=0) by simon.songbird.com (8.14.4/8.14.4/Debian-4.1ubuntu1.1) with ESMTP id 0BEID3HM000766 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Mon, 14 Dec 2020 10:13:03 -0800 To: Michael Thomas , dmarc@ietf.org References: <20201211173722.6B4DF29782C7@ary.qy> <52077ae3-0b6a-8532-d21d-4f5b51413ded@dcrocker.net> <4289adb4-4ea2-7e4a-2a33-37608fc2e86e@mtcc.com> Reply-To: dcrocker@bbiw.net From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: <7fed242e-a59c-350d-983b-4701146afa9d@dcrocker.net> Date: Mon, 14 Dec 2020 10:09:10 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.5.1 MIME-Version: 1.0 In-Reply-To: <4289adb4-4ea2-7e4a-2a33-37608fc2e86e@mtcc.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] p=quarantine X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 14 Dec 2020 18:09:18 -0000 On 12/14/2020 10:00 AM, Michael Thomas wrote: > When we tell you it's not a problem, Except that the telling was by you.  Alone. And you've yet to respond to the observable fact that receivers have been ignoring the directive language. Or that many folk misunderstand the semantics of DKIM, thinking it means that message authorship is validated. Or... d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Mon Dec 14 10:27: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 30FC63A1252 for ; Mon, 14 Dec 2020 10:27:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.15 X-Spam-Level: X-Spam-Status: No, score=0.15 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, 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=mtcc.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 DW0IbaNoLoSn for ; Mon, 14 Dec 2020 10:27:32 -0800 (PST) Received: from mail-pj1-x102c.google.com (mail-pj1-x102c.google.com [IPv6:2607:f8b0:4864:20::102c]) (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 5F87C3A1244 for ; Mon, 14 Dec 2020 10:27:32 -0800 (PST) Received: by mail-pj1-x102c.google.com with SMTP id l23so7115787pjg.1 for ; Mon, 14 Dec 2020 10:27:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mtcc.com; s=fluffulence; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=snWe+bPZ/UpYJ5TPZNmi1yoOH5exWZ/bFZNmAxax14I=; b=DsWzsTlxbS/ootmUui63Wim/qKHvb/vppcPcQFP2317YtJJQA2MuKyAcdMl+t+T1bI mSE6wuwgg0rmjvUCxmg0GkCQ5UoXtPUhW+y5T/ACahSlJBsLur7a6sZlG+llNrypuHpZ fgGYDShLwhzMmGU2fCFDRblrXayQ07DvIXojgHtXraeBZ5wx16yGYsmh6ABLzEod5K5s pPbcQOomvJDHGa1ogf9p1pxFI7voSQ11XHDJVKFL3UTNmpYRqwk7KU+HZyKn2lkTzhgE WDr1wgcMfUBtBjRdzs9TW+KFQv9bwFwWvWd20Pg0N0i0SfLeQvdR7SnE2N+KX9n9evwJ gQeQ== 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=snWe+bPZ/UpYJ5TPZNmi1yoOH5exWZ/bFZNmAxax14I=; b=Nbx+yDokzXJBGllrUFJFi4b9+bUk/5+2c8MVO9MTz0XIWKQv9WeWhxgalIPOY8uXm4 7KouclNO+Zxjd//RYftYn0RdDZBuThRftqIV10vBhkFZ9E2Dw+dwz1fPwU4oiPVy5Ucn JoZCGfT9VtSfozMi3hUbX4tXS2Ib04nvMcXHh20WmsEcVgx7GhxFsL2DxEGYQFhRGHcc mJIIveWcsQ38Wypk8vy29f6LODlk65GnNLKvb/tr5ROzF+ITCHocL9bfAJui/Vlhfwua KHsU4WGk65CVPFBqSFZiL+8NtPKykhU6Oc83Aw8blO4YHWdqFROS0UbUuBzkFDbq0C70 RK+A== X-Gm-Message-State: AOAM530/D3Ka1yRP2Rsw/9z2WI95Ne69HUh+RAOMVuX4bICsgmtuqn+B sgkqBuFUIf0zTpHq7PbyJB4k8NljUBhbpg== X-Google-Smtp-Source: ABdhPJwjYG8UQ/uccC6rlhE27f72Q1glnzZCrkLYy4A7yq25WlM9WYTqz/TorG9Pw/r3h8TZBB6yDQ== X-Received: by 2002:a17:90a:4892:: with SMTP id b18mr15850503pjh.64.1607970451526; Mon, 14 Dec 2020 10:27:31 -0800 (PST) Received: from mike-mac.lan ([206.107.197.128]) by smtp.gmail.com with ESMTPSA id a22sm20822490pfa.215.2020.12.14.10.27.30 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 14 Dec 2020 10:27:30 -0800 (PST) To: dcrocker@bbiw.net, dmarc@ietf.org References: <20201211173722.6B4DF29782C7@ary.qy> <52077ae3-0b6a-8532-d21d-4f5b51413ded@dcrocker.net> <4289adb4-4ea2-7e4a-2a33-37608fc2e86e@mtcc.com> <7fed242e-a59c-350d-983b-4701146afa9d@dcrocker.net> From: Michael Thomas Message-ID: Date: Mon, 14 Dec 2020 10:27:29 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 MIME-Version: 1.0 In-Reply-To: <7fed242e-a59c-350d-983b-4701146afa9d@dcrocker.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] p=quarantine X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 14 Dec 2020 18:27:34 -0000 On 12/14/20 10:09 AM, Dave Crocker wrote: > On 12/14/2020 10:00 AM, Michael Thomas wrote: >> When we tell you it's not a problem, > > Except that the telling was by you.  Alone. > > And you've yet to respond to the observable fact that receivers have > been ignoring the directive language. > > Or that many folk misunderstand the semantics of DKIM, thinking it > means that message authorship is validated. > I'll ignore the whataboutism, but point out that you have never produced one piece of evidence where the language of p=reject or any of the other previous labels has caused software design decisions to change for the worst. I don't even know what would qualify as a mistake. So yes, I'll take my direct experience of writing code over your indirect innuendo any day. Mike From nobody Mon Dec 14 11:17:43 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FAF43A172D for ; Mon, 14 Dec 2020 11:17:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.05 X-Spam-Level: X-Spam-Status: No, score=0.05 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iecc.com header.b=EZpoas6j; dkim=pass (2048-bit key) header.d=taugh.com header.b=hIS9c27I Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HsxDhfKc9fXd for ; Mon, 14 Dec 2020 11:17:41 -0800 (PST) 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 E86DC3A172B for ; Mon, 14 Dec 2020 11:17:40 -0800 (PST) Received: (qmail 46943 invoked from network); 14 Dec 2020 19:17:39 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=b75b.5fd7ba53.k2012; bh=M2PM5k/dBZdG/i5p3Ng94wJ+gCfiSHJloMdAPcCKzmk=; b=EZpoas6j+M6/T/9T4xRbodAmzBza/K4m7ob3DXwjQrN1EaCpZNt3JvB2rtAiQr6tiodBrCad3wgVeF1VhQ15BsG0WdlHg4IWJRPJZVdbhzPgmu6rqNXGU96kA5vXRF8MkDAtoErqpZdsE3lxhXqSCpTFmVnoFtixi20l1vRhYWUHDV4SK1tG0w9LR+gRyjoUKWn63PemgEXZv2RhMUX668phJy1yZN6Scbj+MECUHfbYUT5aX3kPTbnJdFJZAC3OqJUzpcg0yS5xHvT+1SlJhfmjCcBAbC8iDtYE4OB2GznWnSeCX03NDcqudJYzGb+EgaWJUf4fcIrST94a1CSiVQ== DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=b75b.5fd7ba53.k2012; bh=M2PM5k/dBZdG/i5p3Ng94wJ+gCfiSHJloMdAPcCKzmk=; b=hIS9c27Iev2oECo+yKyOdNID0wSaVmtI5yc9vprZrG8Z7zC2NqS7N/EHkHo7Ww4Em0oVHWfkn9tbuKWzlNmbaqgJMDoJGm4j7MX0e5jt0VsBBa63MIa6En27qISwBpFPzBk4D/m7FiVBd6plPw4Yh8ryTkoZ1I029DcAAyiIzUP+YOa0Ndz4maEd/st9crPSo0NztcYb98yDxtRnM9Sgmjb9ygBGRh6dflJR6lGGnIXna1YIeUxQGvEcMGe4dn1xTQo6KzzWKYH+oil2I18V0Io23BMVEGLiF5d8SbBkTvOpod/5BjAc215ZV8l4EcVsFmfQ8Wwnm/SFNbVj46Rx+A== 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; 14 Dec 2020 19:17:38 -0000 Received: by ary.qy (Postfix, from userid 501) id 17BC329DED65; Mon, 14 Dec 2020 14:17:37 -0500 (EST) Date: 14 Dec 2020 14:17:37 -0500 Message-Id: <20201214191738.17BC329DED65@ary.qy> From: "John Levine" To: dmarc@ietf.org Cc: Alex_Brotman@comcast.com In-Reply-To: Organization: Taughannock Networks X-Headerized: yes Cleverness: minimal Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] Multiple SPF in a single auth_results X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 14 Dec 2020 19:17:42 -0000 In article you write: >I'm seeing a report where the XML contains two SPF records within a single auth_results entity. This doesn't seem correct. It's specifically allowed in the XML schema. In this case I'd guess it is checking the From header domain, the org domain, and the bounce address. I see that bounce.email.peacocktv.com is a CNAME for sparkpostmail.com so it's plausible. Checking all those things seems useless but that doesn't mean it's forbidden. R's, John > > > email.peacocktv.com > pass > > > bounce.email.peacocktv.com > pass > > > mta-218-134.sparkpostmail.com. > none > > From nobody Mon Dec 14 12:02: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 A4D363A1A2B for ; Mon, 14 Dec 2020 12:02:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.196 X-Spam-Level: X-Spam-Status: No, score=-0.196 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GTvohlZ_uyI4 for ; Mon, 14 Dec 2020 12:02:35 -0800 (PST) Received: from mail-ot1-x329.google.com (mail-ot1-x329.google.com [IPv6:2607:f8b0:4864:20::329]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37FB33A1AC0 for ; Mon, 14 Dec 2020 12:02:25 -0800 (PST) Received: by mail-ot1-x329.google.com with SMTP id q25so16996461otn.10 for ; Mon, 14 Dec 2020 12:02:25 -0800 (PST) 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=y5/LZhV61SmMTksV8MRcxX0KlPCcoFa/Rq+KwEOmym8=; b=Ksshgyju1LW9+XMoxi3Wlz896Zjur6xn/N1I27u/XSIqZiGXOm4e6xB97Kjug0BBAd JWY4zCmZ385NbVA7cFPR45G8UIWoKVaXvj0hYH/jTdCK5iMwms9dsFaf+BKp0CUQTvwM RAOQYEiIPGZ1aiSUV90+xIqyKXhmWWi+vgbUcfc1sDRjo35VPVsUnUio7md1Y/SL+C/5 E3EGX5nUMlfqjhJgglVuNvgtZvy9MhuNGlwAWAZ3CmBUT6jErSg6OzEBIMovN2x6Yym1 usViQrGRAL4gqm5XBtpClM5wTbPP42BAiHR8G4N9VNiIzqX4FUYl2y6w9sGwHDcDx5EK WrPQ== 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=y5/LZhV61SmMTksV8MRcxX0KlPCcoFa/Rq+KwEOmym8=; b=kly4pdWSArh5UoptyFnxmFpApiLbW+Jac6XHlBwCiwl6PXAzWDrbnYTutZWgKRFXFZ lQJfQldYxxLM7I9BVuAZHyudlJkMmq9zXKlUd467lCGYSZTBAI7CZV5TsAHpPE9u2iFT aBHd482V/Cr6TFt41Bqp9HsymIMOHTIKOkgOtcDMv9MGDHE1AFkTRlf8LA6v985aiwbt N5jQhZx5yOh3l4yJJdodvQdCa1AnQ4KS2qx7+E/9umCUeXt7YmAOjpqsFljF+bnEWMou 4dPyyoJPV6Z9Lg/OqHIfO3RkGsvmoPt54msox5nYPU8sjYNM/KK2Tganeb9ECHb6Xn6S l1ZA== X-Gm-Message-State: AOAM532hwGCrKALKRZkYT8tfVW9GTmRKayof8/SKQbsucbGfXy0l25MX KG84SRncXE0dSQDaAfKmPhY1sOFYynn/Ngw37UBNXy8G X-Google-Smtp-Source: ABdhPJyl2hxQS+IPfjUbjHJysXRL51oCbs03Xu/CCGHMC80gtOI9tXQn5BOrxmNG3kiSoTA7P9LD9cdGLsbww10o7Vc= X-Received: by 2002:a9d:4b81:: with SMTP id k1mr21217242otf.371.1607976142999; Mon, 14 Dec 2020 12:02:22 -0800 (PST) MIME-Version: 1.0 References: <20201211173722.6B4DF29782C7@ary.qy> <52077ae3-0b6a-8532-d21d-4f5b51413ded@dcrocker.net> <4289adb4-4ea2-7e4a-2a33-37608fc2e86e@mtcc.com> <7fed242e-a59c-350d-983b-4701146afa9d@dcrocker.net> In-Reply-To: From: Tim Wicinski Date: Mon, 14 Dec 2020 15:02:10 -0500 Message-ID: To: Michael Thomas Cc: Dave Crocker , IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000cf947e05b6721eaf" Archived-At: Subject: Re: [dmarc-ietf] p=quarantine X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 14 Dec 2020 20:02:37 -0000 --000000000000cf947e05b6721eaf Content-Type: text/plain; charset="UTF-8" All Can we please stop with the non constructive discussions here? tim On Mon, Dec 14, 2020 at 1:27 PM Michael Thomas wrote: > > On 12/14/20 10:09 AM, Dave Crocker wrote: > > On 12/14/2020 10:00 AM, Michael Thomas wrote: > >> When we tell you it's not a problem, > > > > Except that the telling was by you. Alone. > > > > And you've yet to respond to the observable fact that receivers have > > been ignoring the directive language. > > > > Or that many folk misunderstand the semantics of DKIM, thinking it > > means that message authorship is validated. > > > > I'll ignore the whataboutism, but point out that you have never produced > one piece of evidence where the language of p=reject or any of the other > previous labels has caused software design decisions to change for the > worst. I don't even know what would qualify as a mistake. So yes, I'll > take my direct experience of writing code over your indirect innuendo > any day. > > Mike > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > --000000000000cf947e05b6721eaf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
All
Can we= please stop with the non constructive discussions here?=C2=A0 =C2=A0
=

tim


On Mon, Dec 1= 4, 2020 at 1:27 PM Michael Thomas <mike= @mtcc.com> wrote:

On 12/14/20 10:09 AM, Dave Crocker wrote:
> On 12/14/2020 10:00 AM, Michael Thomas wrote:
>> When we tell you it's not a problem,
>
> Except that the telling was by you.=C2=A0 Alone.
>
> And you've yet to respond to the observable fact that receivers ha= ve
> been ignoring the directive language.
>
> Or that many folk misunderstand the semantics of DKIM, thinking it > means that message authorship is validated.
>

I'll ignore the whataboutism, but point out that you have never produce= d
one piece of evidence where the language of p=3Dreject or any of the other =
previous labels has caused software design decisions to change for the
worst. I don't even know what would qualify as a mistake. So yes, I'= ;ll
take my direct experience of writing code over your indirect innuendo
any day.

Mike

_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
--000000000000cf947e05b6721eaf-- From nobody Mon Dec 14 12:07: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 79A893A1A64 for ; Mon, 14 Dec 2020 12:07:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.152 X-Spam-Level: X-Spam-Status: No, score=0.152 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mtcc.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 At7VLC6hugil for ; Mon, 14 Dec 2020 12:07:08 -0800 (PST) Received: from mail-pl1-x636.google.com (mail-pl1-x636.google.com [IPv6:2607:f8b0:4864:20::636]) (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 EA8DA3A1A62 for ; Mon, 14 Dec 2020 12:07:07 -0800 (PST) Received: by mail-pl1-x636.google.com with SMTP id x18so3294670pln.6 for ; Mon, 14 Dec 2020 12:07:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mtcc.com; s=fluffulence; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=wzs4IPgvrJZNtlfh9E9t5UD5CJTI0fNVTmHxFThz52g=; b=jtQ58vJI9gQVXPTGwyLTQcg3qtX8pM5BkLQx6kUNkRdEAZaY0fCOcg9/DyjtW/BGUM L4KGWmbTewy/pqZ/kXNK9/0olng4zmRSVhty2buZXzMbFdvJd4voLz8MHB29U0Bm2Ou1 ajeZncTHx5h2IZmiBkHrIthilZcf5ES6c7ffiAmrELlLxEl5IY8LEzIZmBD80jTo0B5s Tz9G4ocFzvHVMH8uCZfuKRbXnYxP+6+21/znyJNFMHMQredkV0pmP0vOdtk0NS1zlBJ5 +e0QkWVHtWCKpt08YFrCt5Obry8rybUTpYruUUpq5XpOm520qlM3lf2djqFKfLldTA2n bkrQ== 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=wzs4IPgvrJZNtlfh9E9t5UD5CJTI0fNVTmHxFThz52g=; b=t7BSDULnXgL3TqzEYyLwnXCoMdzeUXoug7bYBg4OX3+kLises+7RV//65vFt0E4cnm a54rq7r0Vs1trWLxWgpKr8VXtJ+kJH+ZUoU4Qpx+GLAutTO488bhYy/7zeXBpitlI0o+ zPz2SGwivdS+L+HmP/iT3ndevbKmMIiDto9X7QiWWD8hJGoJx9pdx0jtRLmW4NX2QrTZ wo+nWQ5pNqwKbT7wfV517RXmfIFd19gxi5e7wvNEXrmhu+4x/xNmdEBBE2Ujk9aJxnNT VHMtrGTgo07+hi6y9wOzV848GRFSUQXdPRYbSrOiF7Og542ul2NwoYQf4TCCIOrRw8PN 4H0Q== X-Gm-Message-State: AOAM531daYLHCcNSTkQ8M70Re5LLVSTRL+tC5ZfL13Vq67+eo+m/OoYW PqlPGoPtmSGqkhEMWvVssYoOq3sW99blUQ== X-Google-Smtp-Source: ABdhPJxKNT1cCyq9VHsx9y5CpeU6K8MJpQG8SgBugr3QCEW7K5ieJJaFQ3Amr3dCj8s7SGL9mWNWVg== X-Received: by 2002:a17:902:ee11:b029:db:c0d6:581a with SMTP id z17-20020a170902ee11b02900dbc0d6581amr24427775plb.54.1607976426816; Mon, 14 Dec 2020 12:07:06 -0800 (PST) Received: from mike-mac.lan ([206.107.197.128]) by smtp.gmail.com with ESMTPSA id t12sm17218768pgu.75.2020.12.14.12.07.05 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 14 Dec 2020 12:07:05 -0800 (PST) To: Tim Wicinski Cc: Dave Crocker , IETF DMARC WG References: <20201211173722.6B4DF29782C7@ary.qy> <52077ae3-0b6a-8532-d21d-4f5b51413ded@dcrocker.net> <4289adb4-4ea2-7e4a-2a33-37608fc2e86e@mtcc.com> <7fed242e-a59c-350d-983b-4701146afa9d@dcrocker.net> From: Michael Thomas Message-ID: <8170c931-0abe-f7c9-ca7d-e6c78ee9033f@mtcc.com> Date: Mon, 14 Dec 2020 12:07:04 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------350E572A6567B1CDF0E59BC6" Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] p=quarantine X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 14 Dec 2020 20:07:09 -0000 This is a multi-part message in MIME format. --------------350E572A6567B1CDF0E59BC6 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 12/14/20 12:02 PM, Tim Wicinski wrote: > All > > Can we please stop with the non constructive discussions here? > It would be helpful to just rule anything about the semantics of p=reject as out of scope. It is what hijacked my original question for which I haven't gotten an answer. Mike --------------350E572A6567B1CDF0E59BC6 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit


On 12/14/20 12:02 PM, Tim Wicinski wrote:
All

Can we please stop with the non constructive discussions here?   


It would be helpful to just rule anything about the semantics of p=reject as out of scope. It is what hijacked my original question for which I haven't gotten an answer.

Mike

--------------350E572A6567B1CDF0E59BC6-- From nobody Mon Dec 14 14:14: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 2F2023A0B6E for ; Mon, 14 Dec 2020 14:14:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.198 X-Spam-Level: X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=valimail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5DgUaOBLYjrG for ; Mon, 14 Dec 2020 14:14:28 -0800 (PST) Received: from mail-qk1-x72b.google.com (mail-qk1-x72b.google.com [IPv6:2607:f8b0:4864:20::72b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B3F23A0B58 for ; Mon, 14 Dec 2020 14:14:28 -0800 (PST) Received: by mail-qk1-x72b.google.com with SMTP id c7so17285607qke.1 for ; Mon, 14 Dec 2020 14:14:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=3IV6NV27IcUpCFFE7plVem0RxQ3wbz0gq7yyhFJVKGo=; b=SAMJ5RVoXta+HZgFTN/Z2bLlm9SaBXuJrWKNC5/jEJlJOc3Kf22sbkjbV5VGjg+A+w BTBqxV4c3xltJydEneoEvn9AMyd4wmahcVhKtQuskHYo1c1B5SdzxMLK9B2+nh4dsyR2 Nfd2X2wrfMs0aN4GVE+SauocIzMCuqcknnH1pKSlU+J5XJFpkr0g9DilBmCKBRQ1ETVd Cfg3Er+IwfZ0wn67Q7/ldzT5aQDy2Eh2gEUVF7z/rC8Qgeh4ZZceped6HCfncxEUa1o/ 249KWgfLEt9ePEfCZ1HpwurtD6CziiVrhFQQocpRX6ItCSSU3xX3oCRO7aciY02KRi4/ AKoQ== 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=3IV6NV27IcUpCFFE7plVem0RxQ3wbz0gq7yyhFJVKGo=; b=Ve6Oif2Rg9M4drEFiS+c9QzVu1z4FV5aYfPR0a7crzBXUZKkwJc3QJTYgukeHl9NRh fp/Sg6HKu6W3l6uQjzzCyKpuSFfe8f3nH2jO1Z17zfBOAr6a4lx/dvioDzTTNZ7/OedP obkPsgdfyOGSG216Z6raitc71u/mTKk0MszOQuHZioROTHRnEELr5gpI+NzMaMJSu56d /5yIwO2cahDXkPFm9kGgFQAy0NYUyVQOWEMgQThvrWk0At30hyb4KP/aihVw4Ieg3yHu Q9W/NWIBlBzriFnQGcn0P+eekT+9EInarNrfB5aO5lCYlbr/v5+hYwPtOsX071lfuRsZ jSIQ== X-Gm-Message-State: AOAM532moLWEoczLfkid1ZiVLNXVDKmuA06vHdgnnRb+1VeIx5QWyzZD mMZ/JZcCrBgYFuKIxLkygvZfNSt3M/LKvCiLPUP/PiVUMstNWw== X-Google-Smtp-Source: ABdhPJxnLG+VhK6xT7CByuAsRT/5Yp2Nw47QfViqcRZ1quXXL0K+nXAakXq6ZBkwPDXaA+xwybMVVEt7uDaPbOLz8r4= X-Received: by 2002:a05:620a:1f9:: with SMTP id x25mr11300479qkn.456.1607984067205; Mon, 14 Dec 2020 14:14:27 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Todd Herr Date: Mon, 14 Dec 2020 17:14:11 -0500 Message-ID: To: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="00000000000021762905b673f780" Archived-At: Subject: Re: [dmarc-ietf] Multiple SPF in a single auth_results X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 14 Dec 2020 22:14:30 -0000 --00000000000021762905b673f780 Content-Type: text/plain; charset="UTF-8" On Mon, Dec 14, 2020 at 11:10 AM Henning Krause wrote: > Perhaps the first one is for the mail-from-domain and the other is for > the EHLO host? > > > > -----Original Message----- > > From: dmarc [mailto:dmarc-bounces@ietf.org] On Behalf Of Brotman, Alex > > > > > > bounce.email.peacocktv.com > > pass > > > > > > mta-218-134.sparkpostmail.com. > > none > > > I would tend to agree with Herr Krause, based on what I remember about SparkPost's host naming convention and such. -- *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. --00000000000021762905b673f780 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Dec 14, 2020 at 11:10 AM Henning = Krause <mail=3D40he= nningkrause.eu@dmarc.ietf.org> wrote:
Perhaps the first o= ne is for the mail-from-domain and=C2=A0 the other is for the EHLO host?

> -----Original Message-----
> From: dmarc [mailto:dmarc-bounces@ietf.org] On Behalf Of Brotman, Alex

<= br> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <spf>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<domain>bounce.email.peacocktv.com</domain>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<result>pass</= result>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 </spf>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <spf>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<domain>mta-218-134.sparkpostmail.com.</domain>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<result>none</= result>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 </spf>
=C2=A0I would tend to agree with Herr Krause, based on what I = remember about SparkPost's=C2=A0host naming convention and such.
<= div>
--

Todd Herr | Sr. Technical Program Manager
p: 703.220.415= 3


This email and all data transmitted with it con= tains confidential and/or proprietary information intended solely for the u= se of individual(s) authorized to receive it. If you are not an intended an= d authorized recipient you are hereby notified of any use, disclosure, copy= ing or distribution of the information included in this transmission is pro= hibited and may be unlawful. Please immediately notify the sender by replyi= ng to this email and then delete it from your system.

--00000000000021762905b673f780-- From nobody Mon Dec 14 19:26: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 DBA1F3A00D8 for ; Mon, 14 Dec 2020 19:26:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.814 X-Spam-Level: X-Spam-Status: No, score=0.814 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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, T_SPF_TEMPERROR=0.01, 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 dDT8301HC36C for ; Mon, 14 Dec 2020 19:26:15 -0800 (PST) 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 667CF3A00D3 for ; Mon, 14 Dec 2020 19:26:15 -0800 (PST) Received: by mail-vs1-xe2c.google.com with SMTP id p7so10223220vsf.8 for ; Mon, 14 Dec 2020 19:26:15 -0800 (PST) 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=D83BCODfkINMB4PrC6J0R4BNoKmRlnk5fkIirKridp8=; b=FY0la+JTuizg3V235R3Uy2ax/ro/qGhwjLXiROo4Jk5bbWqR/r/LQUp2Evzpm7xg2K sMxbltf5OXBxgZPioRer2AAFefvvkXFuBjUuKFTo4I01wXDip5k4ZGrbdYPOcwmbBSX0 +3i4+yfRELm1OuQIrOsCwxBpr8bSWeWn/CsOngfa2tQPMi7DAHuUj9cZ/Aj+gkeK4Lf/ nalwcZqN53uNiGKaqqcaRLZvWcDVKs+1z2iaLY9FUo9n7EqhbvHK6VVQT8UFjsdYW4ZI 500EWKIhuSbX7da3cBaIxNJ7I/Dz+zTwBBnVShuE/8sme+jfp1H9f05Nz45VazwoTYMr KoWA== 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=D83BCODfkINMB4PrC6J0R4BNoKmRlnk5fkIirKridp8=; b=Q/DvoCrz7jy72Jt3lCAPPiQrL1pdA1kp5sRr2F5WqwLkvAqos0I2/Nbd4Pr39xofmw 1MYRzPD++6Kn3syz3+2nr+IP8rNavPq5LVUCua4Ti9AbboTxKh2t86rcfJ9gdAl/3H89 kKkRsBNukRpzUX48P7B/ZXd1E0qux7P2sQkJtZBE4riLVUmpBuyUe/B/DLQ2pV8/3Xbh 6tsbXiV8bG1gtaOZ/NXjRsrBDiwDJgdU4xeo33DdNN7ItiaDxzNLKzrxSr1ZKAdm+eNn +4D01EOZwVii/I3PdMxWuiB+Z+cdSmnzzJNf7Xyg2xEr63Ln67ZN/UTwIFwkiBQmaSrI h8ug== X-Gm-Message-State: AOAM53220uTVnrH3de6tMdcWuiEzh5icrPPLUCRjttbyVoCimUJ9wt9Q QeAjfbQED7RC6UQPqGTMD39B+aOmW/QuKo6+2Fff7HbTX+4= X-Google-Smtp-Source: ABdhPJyyKfFeueVl5+O8D9SnbjrTR4yFmzwY733FfxiIE8JSbYfs6J/hXc3rjBdJQJ+Vx9ub4kdujEJ0pGHXEeJn+qk= X-Received: by 2002:a67:6e83:: with SMTP id j125mr10492221vsc.16.1608002774037; Mon, 14 Dec 2020 19:26:14 -0800 (PST) MIME-Version: 1.0 References: <20201211173722.6B4DF29782C7@ary.qy> In-Reply-To: From: Douglas Foster Date: Mon, 14 Dec 2020 22:26:03 -0500 Message-ID: To: IETF DMARC WG Content-Type: multipart/alternative; boundary="00000000000024f97005b678520b" Archived-At: Subject: Re: [dmarc-ietf] p=quarantine X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 15 Dec 2020 03:26:23 -0000 --00000000000024f97005b678520b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sorry about the confusion caused by my typing failures. What I meant: First party - From address aligns with SMTP address. Can be validated with SPF or DKIM. Third party - From address and SMTP address are in different domains. Can be validated with DKIM only. I am open to suggestions for better nomenclature. But what I am trying to figure out is under what circumstances a DMARC policy can be considered actionable. Do I conclude that "p=3Dquarantine" means "domain is still collecting data, so results are unpredictable"? Or do I conclude that it means "Domain is fully deployed and failure to validate is a highly suspicious event?" Take the case of a SMTP-aligned message which does not have a DKIM signature. If it is received directly, it is DMARC compliant. If it is received indirectly, it is a presumed spoof. It cannot be both valid and spoofed. Whether the message gets forwarded is not under the sender's control. If I receive it directly it is presumed valid, but does it signal that the domain is still struggling to implement DMARC, so their policy should be ignored on future messages? Or if I receive it indirectly, should I try to reverse engineer whether it was SPF-aligned before it was forwarded? Since all messages need to be DKIM-signed to survive a possible forward, should SPF even be part of the DMARC criteria? I am simply wondering if a DMARC policy has enough reliable information to be of any value, at least for any setting other than p=3Dreject pct=3D100. This is intertwined with the ambiguity about what the sender means for any policy other than p=3Dreject pct=3D100. My opening post was an attempt to define milestones that should be associated with specific settings. But maybe the only certainty is that the domain is collecting data and consequently spoof-prevention must be based on evidence other than the DMARC policy. DF On Mon, Dec 14, 2020 at 10:36 AM Laura Atkins wrote: > > > On 14 Dec 2020, at 15:11, Douglas Foster < > dougfoster.emailstandards@gmail.com> wrote: > > I called that a third-party message, since the RFC5321.MailFrom domain is > different from the RFC5322.From domain. > > > No, you didn=E2=80=99t. > > Third-party direct messages ( RFC5321.MailFrom domain =3D RFC5322.From > domain ) > > I think =E2=80=98first party=E2=80=99 and =E2=80=99third-party=E2=80=99 a= re problematic definitions in any > case and I=E2=80=99m not sure I understand what your goal is here. Who ar= e you > considering =E2=80=98party=E2=80=99? > > laura > > I am open to revisions of how the boundaries should be defined, but as I > said in my reply just now to Michael Hammer, we need to define those > boundaries in a way that both sender and receiver understand. This is th= e > full problem description: > > We have these three types of senders: > - first-party senders > > > - third-party senders > - spoofers > > We have these four verification states at initial transmission: > - none > - spf only > - dkim only > - spf and dkim > > We have these 9 routing scenarios: > - direct (1) > - indirect (8) > with and without SMTP rewrite > with and without FROM rewrite > with and without content modifications > > Upon receipt, we have these verification states: > - Not verified > - SPF only > - DKIM only > - SPF and DKIM > > For messages that do not verify, the evaluator uses sender policy (none, > quarantine, reject) to categorize the message as either "verifiably > spoofed" or "uncertain". What is the algorithm for doing so? > > DF > > > On Mon, Dec 14, 2020 at 5:05 AM Laura Atkins > wrote: > >> >> >> On 13 Dec 2020, at 21:44, Douglas Foster < >> dougfoster.emailstandards@gmail.com> wrote: >> >> Based on this discussion, it seems evident that p=3Dreject should includ= e >> language about in-transit modifications which are outside the control of >> the source domain, and consequently outside the ability of DMARC to guid= e >> recipients. Extending from that, I thought it would be helpful to >> specify some shared assumptions between sender and evaluator to make the >> interpretation of the settings less subjective. I call this the "Minim= um >> expected implementation at pct=3D100". >> >> >> What about messages which do not have SPF verification but do have DKIM >> verification? A significant number of email platforms use their own doma= ins >> in the 5321.from address but have the customer sign with DKIM. In many >> cases, DKIM signing is actually free, whereas making the SPF align is a >> paid service. >> >> p=3Dnone >> Minimum expected implementation at pct=3D100: >> All first-party direct messages (RFC5321.MailFrom domain =3D RFC5322.Fro= m >> domain) are verifiable using SPF, but may not have a DKIM signature. >> Third-party direct messages ( RFC5321.MailFrom domain =3D RFC5322.From >> domain ) may or may not have DKIM signatures. >> Consequently, indirect messages are often not verifiable using DMARC. >> >> >> p=3Dquarantine >> Minimum expected implementation at pct=3D100: >> All first-party direct messages (RFC5321.MailFrom domain =3D RFC5322.Fro= m >> domain) are verifiable using SPF, but may not have a DKIM signature. >> Third-party direct messages ( RFC5321.MailFrom domain =3D RFC5322.From >> domain ) are verifiable using DKIM signatures. >> Consequently, indirect messages may or may not be verifiable, depending >> whether the forwarded message included a signature. >> >> p=3Dreject >> Minimum expected implementation at pct=3D100: >> All first-party direct messages (RFC5321.MailFrom domain matches >> RFC5322.From domain) are verifiable using SPF and DKIM. >> Third-party direct messages ( RFC5321.MailFrom domain does not match >> RFC5322.From domain ) are verifiable using DKIM signatures. >> Indirect messages which are not modified in transit are verifiable using >> DKIM signatures. >> Indirect messages which are modified in transit are outside the scope of >> DMARC and must be evaluated by other criteria available to the recipient >> system. >> >> Having defined the policies/categories in these terms, the logical next >> step would be a best practices document which discusses how an evaluator >> might distinguish between direct messages, indirect unmodified messages, >> and indirect modified messages. ARC obviously plays a role in making >> these distinctions easier to determine and less error-prone. >> >> Doug Foster >> >> >> On Sat, Dec 12, 2020 at 1:42 PM Dave Crocker wrote: >> >>> On 12/11/2020 9:37 AM, John Levine wrote: >>> > In article <1AC986FF-507B-4917-9C6D-D84E9337FC7A@wordtothewise.com> >>> you write: >>> > aligned is not authorized by the domain owner and may be discarded or >>> rejected by the recipient. >>> > Naah. >>> > >>> > p=3Dreject: all mail sent from this domain should be aligned in a DMA= RC >>> > compliant way. We believe that unaligned mail is from unauthorized >>> > senders so we ask receivers to reject it, even though that might mean >>> > some of our authorized senders' mail is rejected too. >>> >>> >>> As soon as this specification text, here, contains language about how >>> this information is to be used, should be used, or could be used, it >>> crosses over into creating confusion about expectations of receiver >>> handling. >>> >>> It encourages misguided language such as the receiver 'overriding' >>> sender policy. The sender has no policies about receiver behavior, >>> because there is no relationship between them. Using milder language >>> here doesn't help, because readers typically do not read like legal or >>> technical scholars. >>> >>> DMARC provides information, not direction. >>> >>> The spec already contains misguided perspective by talking about >>> 'policy' records and, even worse, "policy enforcement considerations". >>> >>> If the document must contain language about receiver choices in message >>> disposition, move it to an overtly non-normative discussion section tha= t >>> legitimately covers a wide range of things that receivers do or don't d= o >>> (cast as things they might or might not do.) And make sure none of the >>> language hints at sender 'policy', overrides, or the like. >>> >>> >>> d/ >>> >>> -- >>> Dave Crocker >>> dcrocker@gmail.com >>> 408.329.0791 >>> >>> Volunteer, Silicon Valley Chapter >>> American Red Cross >>> dave.crocker2@redcross.org >>> >>> _______________________________________________ >>> dmarc mailing list >>> dmarc@ietf.org >>> https://www.ietf.org/mailman/listinfo/dmarc >>> >> _______________________________________________ >> dmarc mailing list >> dmarc@ietf.org >> https://www.ietf.org/mailman/listinfo/dmarc >> >> >> -- >> 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 >> >> >> >> >> >> >> >> _______________________________________________ >> dmarc mailing list >> dmarc@ietf.org >> https://www.ietf.org/mailman/listinfo/dmarc >> > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > > > -- > 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 > > > > > > > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > --00000000000024f97005b678520b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Sorry about the confusion caused by my typing failures.What I meant:
First party - From address aligns with SMTP = address.=C2=A0 Can be validated with SPF or DKIM.
Third party - F= rom address and SMTP address are in different domains.=C2=A0 Can be validat= ed with DKIM only.
I am open to suggestions for better nomen= clature.
=C2=A0=C2=A0
But w= hat I am trying to figure out is under what circumstances a DMARC policy ca= n be considered actionable.=C2=A0 =C2=A0Do I conclude that "p=3Dquaran= tine" means "domain is still collecting data, so results are unpr= edictable"?=C2=A0 =C2=A0Or do I conclude that it means "Domain is= fully deployed and failure to validate is a highly suspicious event?"=

Take the case of a SMTP-aligned message which doe= s not have a DKIM signature.=C2=A0 =C2=A0If it is received directly, it is = DMARC compliant.=C2=A0 =C2=A0If it is received indirectly, it is a presumed= spoof.=C2=A0 =C2=A0 It cannot be both valid and spoofed.=C2=A0 =C2=A0Wheth= er the message gets forwarded is not under the sender's control.=C2=A0 = =C2=A0If I receive it directly it is presumed valid, but does it signal tha= t the domain is still struggling to implement DMARC, so their policy should= be ignored on future messages?=C2=A0 =C2=A0Or if I receive it indirectly, = should I try to reverse engineer whether it was SPF-aligned before it was f= orwarded?=C2=A0 =C2=A0
Since all messages need to be DKIM-signed = to survive a possible forward, should SPF even be part of the DMARC criteri= a?

I am simply wondering if a DMARC policy has= enough reliable information to be of any value, at least for any setting o= ther than p=3Dreject pct=3D100.=C2=A0 This is intertwined with the ambiguit= y about what the sender means for any policy other than p=3Dreject pct=3D10= 0.=C2=A0 =C2=A0My opening post was an attempt to define milestones that sho= uld be associated with specific settings.=C2=A0 =C2=A0But maybe the only ce= rtainty is that the domain is collecting data and consequently spoof-preven= tion must be based on evidence other than the DMARC policy.

<= /div>
DF


On Mon, Dec 14, 2020 at 10:36 AM Lau= ra Atkins <laura@wordtothewis= e.com> wrote:


On 14 Dec 2020, at 15:11, Douglas Foster <dougfoster.email= standards@gmail.com> wrote:

I called = that a third-party message, since the RFC5321.MailFrom domain is different = from the RFC5322.From domain.

N= o, you didn=E2=80=99t.

Third-party direct messages= ( RFC5321.MailFrom domain =3D RFC5322.From domain )

I think =E2=80=98first party=E2=80=99 and =E2=80=99third-party=E2=80=99 = are problematic definitions in any case and I=E2=80=99m not sure I understa= nd what your goal is here. Who are you considering =E2=80=98party=E2=80=99?=

laura

I am open to revisions of how the boundaries should be d= efined, but as I said in my reply just now to Michael Hammer, we need to de= fine those boundaries in a way that both sender and receiver understand.=C2= =A0 This is the full problem description:

We have = these three types of senders:
- first-party senders

-= third-party senders
- spoofers

We have = these four verification states at initial transmission:
- none
- spf only
- dkim only
- spf and dkim

We have these 9 routing scenarios:
- direct (1)
- indirect (8)
=C2=A0 =C2=A0 with and without SMTP rewri= te
=C2=A0 =C2=A0 with and without FROM rewrite
=C2=A0 = =C2=A0 with and without content modifications

Upon= receipt, we have these verification states:
- Not verified
=
- SPF only
- DKIM only
- SPF and DKIM
For messages that do not verify, the evaluator uses sender pol= icy (none, quarantine, reject) to categorize the message as either "ve= rifiably spoofed" or "uncertain".=C2=A0 =C2=A0What is the al= gorithm for doing so?

DF


On Mo= n, Dec 14, 2020 at 5:05 AM Laura Atkins <laura@wordtothewise.com> wrote:


On 13 Dec 2020, at 21:44, Douglas Foster <dougf= oster.emailstandards@gmail.com> wrote:

Based on this discussion, it seems evident that p=3Dreject should include= language about in-transit modifications which are outside the control of t= he source domain, and consequently outside the ability of DMARC to guide re= cipients.=C2=A0 =C2=A0 Extending from that, I thought it would be helpful t= o specify some shared assumptions between sender and evaluator to make the = interpretation of the settings less subjective.=C2=A0 =C2=A0I call this the= "Minimum expected implementation at pct=3D100".

What about messages which do not have SPF verif= ication but do have DKIM verification? A significant number of email platfo= rms use their own domains in the 5321.from address but have the customer si= gn with DKIM. In many cases, DKIM signing is actually free, whereas making = the SPF align is a paid service.=C2=A0

<= div dir=3D"ltr">
p=3Dnone
Minimum expected implementatio= n at pct=3D100:=C2=A0 =C2=A0=C2=A0
All first-party direct message= s (RFC5321.MailFrom domain =3D RFC5322.From domain) are verifiable using SP= F, but may not have a DKIM signature.
Third-party direct messages= ( RFC5321.MailFrom domain =3D RFC5322.From domain ) may or may not have DKIM = signatures.
Consequently, indirect messages are often not verifia= ble using DMARC.

p=3Dquarantine
Minimum ex= pected implementation at pct=3D100:=C2=A0 =C2=A0=C2=A0
All first-= party direct messages (RFC5321.MailFrom domain =3D RFC5322.From domain) are= verifiable using SPF, but may not have a DKIM signature.
Third-p= arty direct messages ( RFC5321.MailFrom domain =3D RFC5322.From domain ) are verifiable using DKIM= signatures.
Consequently, indirect messages may or may not be ve= rifiable, depending whether the forwarded message included a signature.

p=3Dreject
Minimum expected implementa= tion at pct=3D100:=C2=A0 =C2=A0=C2=A0
All first-party direct mess= ages (RFC5321.MailFrom domain matches RFC5322.From domain) are verifiable u= sing SPF and DKIM.
Third-party direct messages ( RFC5321.MailFrom domain does not match RFC5322.From domain ) are verifiable= using DKIM signatures.
Indirect messages which are not modified = in transit are verifiable using DKIM signatures.
Indirect message= s which are modified in transit are outside the scope of DMARC and must be = evaluated by other criteria available to the recipient system.
Having defined the policies/categories in these terms, the log= ical next step would be a best practices document which discusses how an ev= aluator might distinguish between direct messages, indirect unmodified mess= ages, and indirect modified messages.=C2=A0 =C2=A0ARC obviously plays a rol= e in making these distinctions easier to determine and less error-prone.

Doug Foster
=C2=A0

On= Sat, Dec 12, 2020 at 1:42 PM Dave Crocker <dcrocker@gmail.com> wrote:
On 12/11/2020 9:37 AM, John L= evine wrote:
> In article <1AC986FF-507B-4917-9C6D-D84E9337FC7A@w= ordtothewise.com> you write:
> aligned is not authorized by the domain owner and may be discarded or = rejected by the recipient.
> Naah.
>
> p=3Dreject: all mail sent from this domain should be aligned in a DMAR= C
> compliant way. We believe that unaligned mail is from unauthorized
> senders so we ask receivers to reject it, even though that might mean<= br> > some of our authorized senders' mail is rejected too.


As soon as this specification text, here, contains language about how
this information is to be used, should be used, or could be used, it
crosses over into creating confusion about expectations of receiver
handling.

It encourages misguided language such as the receiver 'overriding' =
sender policy.=C2=A0 The sender has no policies about receiver behavior, because there is no relationship between them. Using milder language
here doesn't help, because readers typically do not read like legal or =
technical scholars.

DMARC provides information, not direction.

The spec already contains misguided perspective by talking about
'policy' records and, even worse, "policy enforcement consider= ations".

If the document must contain language about receiver choices in message disposition, move it to an overtly non-normative discussion section that legitimately covers a wide range of things that receivers do or don't d= o
(cast as things they might or might not do.)=C2=A0 And make sure none of th= e
language hints at sender 'policy', overrides, or the like.


d/

--
Dave Crocker
dcrocker@gmail.com<= /a>
408.329.0791

Volunteer, Silicon Valley Chapter
American Red Cross
dave.crocke= r2@redcross.org

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

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

Laura Atkins
Word to the Wise
<= div>laura@word= tothewise.com
(650) 437-0741

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






_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
_______________________________________________
dmarc mailing list
dmarc@ietf.org
http= s://www.ietf.org/mailman/listinfo/dmarc
--=C2=A0
Having an Email = Crisis?=C2=A0 We can help! 800 823-9674=C2=A0

Laur= a Atkins
Word to the Wise
(650)= 437-0741

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







_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
--00000000000024f97005b678520b-- From nobody Mon Dec 14 19:36: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 36B0E3A0127 for ; Mon, 14 Dec 2020 19:36:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.15 X-Spam-Level: X-Spam-Status: No, score=0.15 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, 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=mtcc.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 P_AQK4d0f05t for ; Mon, 14 Dec 2020 19:36:29 -0800 (PST) Received: from mail-pf1-x42a.google.com (mail-pf1-x42a.google.com [IPv6:2607:f8b0:4864:20::42a]) (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 3137C3A0121 for ; Mon, 14 Dec 2020 19:36:29 -0800 (PST) Received: by mail-pf1-x42a.google.com with SMTP id 131so13617963pfb.9 for ; Mon, 14 Dec 2020 19:36:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mtcc.com; s=fluffulence; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=XZtE5y/9diEkZRNWCin3wn2quS4Unif2Wmvw4trW3G4=; b=fXbtFyhDg/ksCyRKpThXqnmMTdmD0Z0/LdMXC/T7wk6fclEfVMiGiAIxB1MxGT+9Hr 1xFep56A0FFY8S3Y9rrIn/taQVyOJfgqexy7eaHNdN2R/SVipKKvbfiN+TByTVV0PuLE Y4cxZFnE98kF+BwTyFr0TVr6k/USID6Si/f+wWbvjbVITPlO5B/kPfsosbwJu+dVMwJp zMUJi09Xe7iRnYbF2Wlqbshs0yz3+SHK39FPkT0Vay306o3Pb5pVCOPRE0bJDotUquL9 T6qc/AbcIBmbpZnHcUWs0x1gr4G3j9RbMJNF+A+0H+8wZl75BviN4nau0n/+u+4aUv3d cadw== 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=XZtE5y/9diEkZRNWCin3wn2quS4Unif2Wmvw4trW3G4=; b=tS86LRwrZ0/tgk0OxvYBzY3mfxmwij9Pbeac00m54RxA/dMxcM+Z4e9eXDxXtZhChO 8dvrMtDL7xfr/eubUaEq7Ycq0ZJrXLD/Mg+2ZWLtF2JQ++JAJPUVOSOCbP6JpOD3SnWM z0uBwHFBbDMIFOuhCVJdqujAs2wroeJJEp5cA1FBN6UBBspnlXqulhD5wqUty1gzEw2W GzPQNWQmwPmiIcjFgbbldNfQYMmgpYEfPlsFYNPOEfYaiPjA3lXV2MhKhSh5s4R2AfBh zXX776/T1IoZCWxgGgpPfcARPGPwnKyWX48uFUBZ4woay4KTSaIOgrBNHZk7jBRl45O3 vRUQ== X-Gm-Message-State: AOAM533hcIWDQQUp/FhsKty9Jx/0kW+1h/przPAl+tXP0ctp1/6cwL0u bbmMcKJyMf9yUOdhuo3m0VaiZR+Sr35Mdg== X-Google-Smtp-Source: ABdhPJxruWT0JxYz28hJs1Mc94J0dsQa+alWRVlZ2uIXx9lfTtku83Cjqm78CDgOC8tICQKAn5DBbg== X-Received: by 2002:a62:3582:0:b029:19e:4935:bea2 with SMTP id c124-20020a6235820000b029019e4935bea2mr26360755pfa.34.1608003388115; Mon, 14 Dec 2020 19:36:28 -0800 (PST) Received: from mike-mac.lan ([206.107.197.128]) by smtp.gmail.com with ESMTPSA id u12sm20636211pfn.88.2020.12.14.19.36.26 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 14 Dec 2020 19:36:27 -0800 (PST) To: dmarc@ietf.org References: <20201211173722.6B4DF29782C7@ary.qy> From: Michael Thomas Message-ID: <02f786e5-b7cd-9a89-e3e3-73594f3bcda0@mtcc.com> Date: Mon, 14 Dec 2020 19:36:26 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.5.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] p=quarantine X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 15 Dec 2020 03:36:30 -0000 On 12/14/20 7:26 PM, Douglas Foster wrote: > > But what I am trying to figure out is under what circumstances a DMARC > policy can be considered actionable.  Do I conclude that > "p=quarantine" means "domain is still collecting data, so results are > unpredictable"?   Or do I conclude that it means "Domain is fully > deployed and failure to validate is a highly suspicious event?" Yeah, that's why I question whether there is something actionable and whether this is so much wishful thinking. Somebody did say that they took action on it (gmail?), but i'm not sure whether that is a good thing or a bad thing. For mailing lists, that would seemingly be a bad thing, but if you're of the mind that mailing lists are a security bug and not a feature that might be contradictory. Mike From nobody Mon Dec 14 22:07: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 9D6293A0A9C for ; Mon, 14 Dec 2020 22:07:03 -0800 (PST) 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, 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 1fNQ05sA4AYI for ; Mon, 14 Dec 2020 22:07:01 -0800 (PST) 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 A471F3A0A97 for ; Mon, 14 Dec 2020 22:07:01 -0800 (PST) Received: by mail-qk1-x72c.google.com with SMTP id d14so17429959qkc.13 for ; Mon, 14 Dec 2020 22:07:01 -0800 (PST) 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=H52Dt0x5iAqHFLDMCKS+E7IWqUsBKu8zkKrRtjhEatQ=; b=hyXu1/FuniB7iUt/o6MLdDhfo010Boe/fn4T1nHZRh9fQJvrbb4bUZJhqq++5oTgC2 AthET3zrL6VCdI1aQSEPE1kjfRV+r3VwlJbgjKiUlFt9MZRemt9KLWFHRmDugh+zBujO 5qsn9xi8WPyxCP5d4HPPZw8+grPoNWA+5Z2OC0V4Sau6Xgk0OhyIRR+3L+/C0hWxATKI AoNGWTw4hMz+iRuDI4SDDYkTtejrl/AlVXbfpiD0h5ZMnQ5RvnNOk6S+gfmHEGUA+Zvv 1GoBMUi1V66QU6g/CVW/sP8sRiM/LrIhVfiTtLKpA+OUwIKhE15s0DlBg20PgQ0QTgf7 +d/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=H52Dt0x5iAqHFLDMCKS+E7IWqUsBKu8zkKrRtjhEatQ=; b=dkmGCReDhMRBDMedD8UIJ4pcoGUTejmpfNdV67UPM/C1XYZwR6VNDCOFZzxcSFxLlk /1Ejz/A/EwvTiQR4IXevXlbNiey7NVfVpShpMJPNPcaRVXIF1hOtW4dhToF1ridm93G5 gokMuK87X9gF4N4t4fxRSw9HDsvVMq1gQOoDSPjXg6lwoEYl50bUN0CkXIVVlYqupM3j jFXiRYCijf4zzhmIq4FRbX/d6cJXD6NQEPWCMSNwLnlPweERE4I7nQdcofsCRz7s9fn8 4CAwpQjr8pyu5qSUiEBzg/EKle4lwoIS8GqKbTxT5sObexxu9KLh+JMWyNVtEixpy2i+ Lqag== X-Gm-Message-State: AOAM532WhE0FSR0P6tRyTEEorVa/+a3Of4WWhGoUxMdkI4d/Dov3W3jP IhTbOumnNDcu77hyLtjppk9s/cMkGodw2WUsd6o= X-Google-Smtp-Source: ABdhPJy7s7m13QDOzqjFGu7Zh6hW7BB/cJHA2AIqCoQG8xDzgcmPSwiyGBBBJCPm0brqPoip4fQdkyVQoOQ/FkAsbyU= X-Received: by 2002:a05:620a:1264:: with SMTP id b4mr6582786qkl.187.1608012420596; Mon, 14 Dec 2020 22:07:00 -0800 (PST) MIME-Version: 1.0 References: <20201211173722.6B4DF29782C7@ary.qy> In-Reply-To: From: Dotzero Date: Tue, 15 Dec 2020 01:06:49 -0500 Message-ID: To: Douglas Foster Cc: IETF DMARC WG Content-Type: multipart/alternative; boundary="0000000000001fc69a05b67a9137" Archived-At: Subject: Re: [dmarc-ietf] p=quarantine X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 15 Dec 2020 06:07:04 -0000 --0000000000001fc69a05b67a9137 Content-Type: text/plain; charset="UTF-8" On Mon, Dec 14, 2020 at 10:26 PM Douglas Foster < dougfoster.emailstandards@gmail.com> wrote: > Sorry about the confusion caused by my typing failures. > What I meant: > First party - From address aligns with SMTP address. Can be validated > with SPF or DKIM. > Third party - From address and SMTP address are in different domains. Can > be validated with DKIM only. > I am open to suggestions for better nomenclature. > > But what I am trying to figure out is under what circumstances a DMARC > policy can be considered actionable. Do I conclude that "p=quarantine" > means "domain is still collecting data, so results are unpredictable"? Or > do I conclude that it means "Domain is fully deployed and failure to > validate is a highly suspicious event?" > You are way overthinking this. > > Take the case of a SMTP-aligned message which does not have a DKIM > signature. If it is received directly, it is DMARC compliant. If it is > received indirectly, it is a presumed spoof. It cannot be both valid and > spoofed. > Rather than using the word "spoofed", think of it as simply "failed to validate" if it was forwarded. Done. > Whether the message gets forwarded is not under the sender's control. > If I receive it directly it is presumed valid, but does it signal that the > domain is still struggling to implement DMARC, so their policy should be > ignored on future messages? Or if I receive it indirectly, should I try > to reverse engineer whether it was SPF-aligned before it was forwarded? > You appear to be venturing into an area that involves tea leaves and crystal balls - way beyond anything a technical standard can address. An organization publishing a p=quarantine record is making a request that messages purporting to be from their domain be quarantined if they fail to validate. It doesn't matter whether it was sent direct or was handled by an intermediary. Even a certain (very small) percentage of emails sent directly can fail for various reasons. Why is it so difficult to take things at face value? If, as a validating receiver you have data that you believe justifies exercising local policy then you have a choice to make. It really is that simple. > > Since all messages need to be DKIM-signed to survive a possible forward, > should SPF even be part of the DMARC criteria? > Yes, SPF should be a part of DMARC because even with direct mail there can be problems with DKIM signing/signatures for various reasons. The combination of SPF and DKIM signing provides a small but useful increase in the percentage of mail that validates. This statement is based on my experience of having been responsible for systems sending several billions of emails with a p=reject policy. > > I am simply wondering if a DMARC policy has enough reliable information to > be of any value, at least for any setting other than p=reject pct=100. > This is intertwined with the ambiguity about what the sender means for any > policy other than p=reject pct=100. My opening post was an attempt to > define milestones that should be associated with specific settings. But > maybe the only certainty is that the domain is collecting data and > consequently spoof-prevention must be based on evidence other than the > DMARC policy. > Again, "spoofing" is a convenient but inaccurate descriptor. DMARC is a tool intended to prevent direct domain abuse based on the RFC 5322 From email address, nothing more and nothing less. Even if an email message validates for DMARC, it could be a homoglyph or cousin domain email address in the RFC 5322 field. Attempting to overlay the meaning of a published policy with other semantics or trying to guess the underlying intentions is a perilous path for a standards body. Other tools and techniques can and should be applied to messages by Receivers in order to protect their users. Michael Hammer --0000000000001fc69a05b67a9137 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Dec 14, 2020 at 10:26 PM Doug= las Foster <dougf= oster.emailstandards@gmail.com> wrote:
Sorry about the confusion ca= used by my typing failures.
What I meant:
First party - = >From address aligns with SMTP address.=C2=A0 Can be validated with SPF or D= KIM.
Third party - From address and SMTP address are in different= domains.=C2=A0 Can be validated with DKIM only.
I am open t= o suggestions for better nomenclature.
=C2=A0=C2=A0
But what I am trying to figure out is under what c= ircumstances a DMARC policy can be considered actionable.=C2=A0 =C2=A0Do I = conclude that "p=3Dquarantine" means "domain is still collec= ting data, so results are unpredictable"?=C2=A0 =C2=A0Or do I conclude= that it means "Domain is fully deployed and failure to validate is a = highly suspicious event?"

You are way overthinking this.

Take the ca= se of a SMTP-aligned message which does not have a DKIM signature.=C2=A0 = =C2=A0If it is received directly, it is DMARC compliant.=C2=A0 =C2=A0If it = is received indirectly, it is a presumed spoof.=C2=A0 =C2=A0 It cannot be b= oth valid and spoofed.=C2=A0
=C2=A0
Rather than using the word "spoofed", think of it as simply= "failed to validate" if it was forwarded. Done.
= =C2=A0
=C2=A0Whether the message gets forwarded is not under the sen= der's control.=C2=A0 =C2=A0If I receive it directly it is presumed vali= d, but does it signal that the domain is still struggling to implement DMAR= C, so their policy should be ignored on future messages?=C2=A0 =C2=A0Or if = I receive it indirectly, should I try to reverse engineer whether it was SP= F-aligned before it was forwarded?=C2=A0

You appear to be venturing into an area that involves = tea leaves and crystal balls - way beyond anything a technical standard can= address. An organization publishing a p=3Dquarantine record is making a re= quest that messages purporting to be from their domain be quarantined if th= ey fail to validate. It doesn't matter whether it was sent direct or wa= s handled by an intermediary. Even a certain (very small) percentage of ema= ils sent directly can fail for various reasons. Why is it so difficult to t= ake things at face value? If, as a validating receiver you have data that y= ou believe justifies exercising local policy then you have a choice to make= . It really is that simple.
=C2=A0
Since all messages= need to be DKIM-signed to survive a possible forward, should SPF even be p= art of the DMARC criteria?

Yes, SPF should be a part of DMARC because even with direct mail ther= e can be problems with DKIM signing/signatures for various reasons. The com= bination of SPF and DKIM signing provides a small but useful increase in th= e percentage of mail that validates. This statement is based on my experien= ce of having been responsible for systems sending several billions of email= s with a p=3Dreject policy.

I am simpl= y wondering if a DMARC policy has enough reliable information to be of any = value, at least for any setting other than p=3Dreject pct=3D100.=C2=A0 This= is intertwined with the ambiguity about what the sender means for any poli= cy other than p=3Dreject pct=3D100.=C2=A0 =C2=A0My opening post was an atte= mpt to define milestones that should be associated with specific settings.= =C2=A0 =C2=A0But maybe the only certainty is that the domain is collecting = data and consequently spoof-prevention must be based on evidence other than= the DMARC policy.

Again,= "spoofing" is a convenient but inaccurate descriptor.=C2=A0 DMAR= C is a tool intended to prevent direct domain abuse based on the RFC 5322 F= rom email address, nothing more and nothing less. Even if an email message = validates for DMARC, it could be a homoglyph or cousin domain email address= in the RFC 5322 field. Attempting to overlay the meaning of a published po= licy with other semantics or trying to guess the underlying intentions is a= perilous path for a standards body. Other tools and techniques can and sho= uld be applied to messages by Receivers in order to protect their users.

Michael Hammer
--0000000000001fc69a05b67a9137-- From nobody Tue Dec 15 00:58: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 131153A0EA2 for ; Tue, 15 Dec 2020 00:58:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.199 X-Spam-Level: X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5 tests=[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.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 dNSHS1Bvb6Z2 for ; Tue, 15 Dec 2020 00:58:05 -0800 (PST) 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 5A3AF3A0E9F for ; Tue, 15 Dec 2020 00:58:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1608022680; bh=7ETuzV6fZkbsmu5rShwkGCEUChNM4u3kB0EHOEYrSfM=; l=2547; h=To:References:From:Date:In-Reply-To; b=BVIBygK1q259fZMsZ93EQ6ud8ETgswQggQac8ppxzwWahJrqXB2kGAvf5iZiFbv/B WfscSFCz2Kf5EWXWcqaZprKZJZAefx9/kMN4ZN7dZ09NbCVfoBbfzrcNy6qMds/5yV w1BSks9LQju2/2Q5L+Ajto3XYsvDxSoOAZ2K2W1yuC3WQ+U3qx31tM4dzCMkp Authentication-Results: tana.it; auth=pass (details omitted) Original-From: Alessandro Vesely 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 00000000005DC026.000000005FD87A98.0000475A; Tue, 15 Dec 2020 09:58:00 +0100 To: "Brotman, Alex" , John R Levine , "dmarc@ietf.org" References: <20201211193845.63466297AE5D@ary.qy> From: Alessandro Vesely Message-ID: <089a1419-bc80-39b9-2825-c9ac8c4f9909@tana.it> Date: Tue, 15 Dec 2020 09:58:00 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] [EXTERNAL] Re: Clarification of Subdomain Reporting X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 15 Dec 2020 08:58:08 -0000 On Mon 14/Dec/2020 16:57:53 +0100 Brotman, Alex wrote: >> From: John R Levine >>> >>> The goal was to clarify the language, without (to the best of our ability) >>> changing the schema. I'd welcome a other attempts at clarifications (if you >>> believe mine introduces structural XML changes). >> >> So it'd say yeah, we know the XML lets you put multiple header_from >> domains in the same report row, but please don't do that, send a separate >> report row for each header_from? I'm still not clear how could two From: domain fall in the same row. Appendix C is very clear that there is a single IdentifierType for each row. And each IdentifierType has exactly one "header_from". I am appalled at the fact that such rule is not given in the text. There has to be a better description in Section 2.2. I'd propose something like: The bulk of a report consists of data for each message received during the reporting period, where each record aggregates messages having similar characteristics. Relevant characteristics are: Then follow with a revised bullet list. It should be a descriptive equivalent of the grammar in Appendix C. The current version doesn't match, obviously, since it confuses ourselves. We cannot ship it as is. > So it should be clarified as such: > > o Data for each Domain Owner's subdomain separately from mail from > the sender's Organizational Domain, even if there is no explicit > subdomain policy > > Perhaps changed to something more like: > > o A separate report should be generated for each 5322.From subdomain, regardless > of which policy domain was used during receipt of messages That's excessive, IMHO. If the recipient is the same, there's no reason to split that data into different reports. > For the other thread with Ale, is there anything wrong with stating both minOccurs/maxOccurs set at "1" so that it's more clear that it must be once, and only once? At the beginning of Appendix C there is a paragraph saying: NOTE: Per the definition of XML, unless otherwise specified in the schema below, the minOccurs and maxOccurs values for each element are set to 1. It's hard to make it clearer than that. Perhaps: NOTE: Per the definition of XML, each element can appear zero or more times, as specified by minOccurs and maxOccurs values. When not explicitly specified, the default value for both attributes is 1. After that, specifying the default might be more confusing than helpful. Best Ale -- From nobody Tue Dec 15 01: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 02B2B3A0EAE for ; Tue, 15 Dec 2020 01:09:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.199 X-Spam-Level: X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5 tests=[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.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 ZraecwT6yN4F for ; Tue, 15 Dec 2020 01:09:13 -0800 (PST) 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 25C363A08D4 for ; Tue, 15 Dec 2020 01:09:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1608023350; bh=42iGXB1CMogAsGPaTszootY++6Iv8TWh0uHISAMNszU=; l=1285; h=To:References:From:Date:In-Reply-To; b=A+RJDji2pp6/R17uROvgjjNlU0Gpy59p10ZbxFJ6UHBRZFCnEiqmIjo7mSnVzjX8b XrxYjrzVOLFB88mncxRxfXYpOJ7Xw2Oua8Dao9hZfN18uMwqK6Jh/Y9G+je+6L8ve6 fMayhNcN1pPqMdsyRuTJXoYjxhSLeY4EPbu//w1J6DNPqLJq/9iNREz1zW1Ha Authentication-Results: tana.it; auth=pass (details omitted) Original-From: Alessandro Vesely 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 00000000005DC026.000000005FD87D36.00004928; Tue, 15 Dec 2020 10:09:10 +0100 To: dmarc@ietf.org References: <20201214191738.17BC329DED65@ary.qy> From: Alessandro Vesely Message-ID: <0fc0e6b8-9ded-998b-2cde-1ef56b970517@tana.it> Date: Tue, 15 Dec 2020 10:09:10 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: <20201214191738.17BC329DED65@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] Multiple SPF in a single auth_results X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 15 Dec 2020 09:09:15 -0000 On Mon 14/Dec/2020 20:17:37 +0100 John Levine wrote: > In article you write: >>I'm seeing a report where the XML contains two SPF records within a single auth_results entity. This doesn't seem correct. > > It's specifically allowed in the XML schema. Yup: > In this case I'd guess it is checking the From header domain, the org > domain, and the bounce address. I see that bounce.email.peacocktv.com is a > CNAME for sparkpostmail.com so it's plausible. One has to guess because the snippet misses the scope of the checked domains: In that sense, it is not correct. It should have been: >> >> >> email.peacocktv.com >> pass >> >> >> bounce.email.peacocktv.com mfrom >> pass >> >> >> mta-218-134.sparkpostmail.com. helo >> none >> >> Best Ale -- From nobody Tue Dec 15 01:50: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 7E68E3A0EFB for ; Tue, 15 Dec 2020 01:50:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.199 X-Spam-Level: X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5 tests=[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.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 9fgfJGHIfkAA for ; Tue, 15 Dec 2020 01:50:14 -0800 (PST) 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 765983A0E5D for ; Tue, 15 Dec 2020 01:50:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1608025810; bh=1OvahXwkDTXHdOkpTYQA6l5MUiAZPSwS9R4r/cmXkdY=; l=1768; h=To:References:From:Date:In-Reply-To; b=B67yFcJlQvIvWuaiT1L1l8x+NivXo6GScaR0p17k3mG9mRGLd8Ep+NqqDHZ180Mts Q6oZGw7w8fV+uLJ0xf1Nhx47smo0LEIH2iyGOsrbfLvd1oyUKw2aZ+PPqVrFbBdSzu 4PcY1/CTi4BvT8WbtDohfn9MXCU+8c45b8kUbF6ng3KpeEqPxFS8wWP0n3Yq/ Authentication-Results: tana.it; auth=pass (details omitted) Original-From: Alessandro Vesely 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 00000000005DC026.000000005FD886D2.00004D40; Tue, 15 Dec 2020 10:50:10 +0100 To: Douglas Foster , IETF DMARC WG References: <20201211173722.6B4DF29782C7@ary.qy> From: Alessandro Vesely Message-ID: Date: Tue, 15 Dec 2020 10:50:10 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] p=quarantine X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 15 Dec 2020 09:50:17 -0000 On Tue 15/Dec/2020 04:26:03 +0100 Douglas Foster wrote: > Sorry about the confusion caused by my typing failures. > What I meant: > First party - From address aligns with SMTP address.  Can be validated with SPF > or DKIM. > Third party - From address and SMTP address are in different domains.  Can be > validated with DKIM only. > I am open to suggestions for better nomenclature. I'm neutral about the nomenclature. However, the definitions lack something. First party is clear. Third party is not: For a nit, albeit unusual, one can use a different bounce address, for any convenience reason. If SPF helo is aligned it is still a first party message. There are other considerations that indicate a the presence and the quality of a third party, such as multiple DKIM signatures, and a Sender: field. Then there are dumb forwarders, who neither sign nor modify messages, nor even the bounce addresses. Second parties? Hm... external aliases? Artifacts of email address portability? > But what I am trying to figure out is under what circumstances a DMARC policy > can be considered actionable.   Do I conclude that "p=quarantine" means "domain > is still collecting data, so results are unpredictable"?   Or do I conclude > that it means "Domain is fully deployed and failure to validate is a highly > suspicious event?" I think quarantine is not necessarily an intermediate step. It is adequate for human mail, where one is not equipped to resend in case of reject. It doesn't cover first/third party differences. I wish there was an intermediate policy, call it p=mlm-validate, that directs a third party to reject if not authenticated, while final recipients can accept it as if p=none. Best Ale -- From nobody Tue Dec 15 08:01: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 DAD733A11FE for ; Tue, 15 Dec 2020 08:01:32 -0800 (PST) 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 EGilsW7g4_XO for ; Tue, 15 Dec 2020 08:01:30 -0800 (PST) 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 1B44D3A11FB for ; Tue, 15 Dec 2020 08:01:29 -0800 (PST) Received: by mail-qk1-x734.google.com with SMTP id 19so19561143qkm.8 for ; Tue, 15 Dec 2020 08:01:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=qliGXxx9e1QBH2P0sXZtXOlwrNK9bEw9+u8hHqoGK/Y=; b=EC/29524s14HjxmsHmjukJmTeEPkh4m2QK9yfDqXH9SZExjAs+UJ9l//OlCkywuXtS 78/wPKiIfzpngQN8oFWgubjVB2WA3wkNzjWAm5MC6cRKgznH7rHEgStMbT2MjxNucy0D s34O3/rfwLlF8DP/Q2InOWVrpKOzcwJW/6c++wqmypS21H1D+EZ2kRvceDJZY+mPK7WW +RI6IljRTq48dyFeCAh95odE0mko18jdbV+okm8fxNvINicTNQjmA1WVWy1ULrjMSwR3 awoTPFm7UMl14GYuCU/TJgMz8EVGLa33bsDC8eQ+L8Z4rSZpQp0YarCRLkKW/DqwY/HM Cf+g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=qliGXxx9e1QBH2P0sXZtXOlwrNK9bEw9+u8hHqoGK/Y=; b=ApGbsIssmUaEVacgKKh1XSlq2XTXFqDlCylNEE+7Gjopcx3ea/DdZ7WZ3xL6sm7l6r XrGXXGiugaRfOiWLncrVfrOjO5nHrpLW3Los1mwjQSnkSZ7H6PW177AFTvvYDy4ZpfQE QaHvPvyFYJdjoUZ6dDKYjaV5eqlnqXC7ocI5ePMCfkh4Ft9bjZ2HpBj67sne/qw/Kkzt Xrj1wdla5I8xj0aj19fMguwwGrDl55dCZSbG9dLqXnlsiji8K5/ss2QK8t6e907Gb9ln rhlHo0q1sFzeRNQ3HV5xXsebzoP1NEE6fMcVFAparR0OTiWv9lsasA/84syikKSGY2hq kkOg== X-Gm-Message-State: AOAM530aMltkLah7K0QE2Ww0Y2Mpu5QpoPPOwIhvA/A++eB/PLjrM+g0 178NTSoMTfCrgUIl3hJXRzM4zrINxXm+QcXtszx/yz5F7mI= X-Google-Smtp-Source: ABdhPJwmQBvu6/Lcoz7w2bzJ/F6DQ11BhpSLWB0hfQMOEauXx1mzAT/xyS5eTti1mvfr4YOjNzk1ObVTyfKfNfa91wc= X-Received: by 2002:a05:620a:1f9:: with SMTP id x25mr15713170qkn.456.1608048088367; Tue, 15 Dec 2020 08:01:28 -0800 (PST) MIME-Version: 1.0 References: <20201211173722.6B4DF29782C7@ary.qy> <02f786e5-b7cd-9a89-e3e3-73594f3bcda0@mtcc.com> In-Reply-To: <02f786e5-b7cd-9a89-e3e3-73594f3bcda0@mtcc.com> From: Todd Herr Date: Tue, 15 Dec 2020 11:01:12 -0500 Message-ID: To: IETF DMARC WG Content-Type: multipart/alternative; boundary="00000000000016dfde05b682df86" Archived-At: Subject: Re: [dmarc-ietf] p=quarantine X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 15 Dec 2020 16:01:33 -0000 --00000000000016dfde05b682df86 Content-Type: text/plain; charset="UTF-8" On Mon, Dec 14, 2020 at 10:36 PM Michael Thomas wrote: > > On 12/14/20 7:26 PM, Douglas Foster wrote: > > > > But what I am trying to figure out is under what circumstances a DMARC > > policy can be considered actionable. Do I conclude that > > "p=quarantine" means "domain is still collecting data, so results are > > unpredictable"? Or do I conclude that it means "Domain is fully > > deployed and failure to validate is a highly suspicious event?" > > > Yeah, that's why I question whether there is something actionable and > whether this is so much wishful thinking. Somebody did say that they > took action on it (gmail?), but i'm not sure whether that is a good > thing or a bad thing. For mailing lists, that would seemingly be a bad > thing, but if you're of the mind that mailing lists are a security bug > and not a feature that might be contradictory. > > I'm not sure there's anything actionable about DMARC's policy values. For receivers, attempts at manually tracking which RFC5322.From domains appear in mail that's authenticated or not with SPF and/or DKIM are ones that are bound to fail due to scaling issues. DMARC provides a solution to this problem, in that if a domain owner publishes a DMARC policy, the receiver now has some information that the owner of the RFC5322.From domain may have an expectation that mail with that domain in the RFC5322.From domain might be authenticated in some fashion, using SPF and/or DKIM. The receiver can use that data point, and the data points collected from DMARC validation checks for that message, as part of the sum total of data it uses to decide its handling of that message. If there is a published DMARC policy for the RFC5322.From domain, and the receiver so chooses, the receiver can also use the p= value in that policy as another data point contributing to the message handling decision, but the receiver is not compelled or required to do so (nor is the receiver compelled or required to even perform DMARC validation checks, or send aggregate and/or failure reports, or even check for the existence of a DMARC policy record for the RFC5322.From domain). For domain owners that publish DMARC policies, the best case is that the owner is announcing to the internet at large that - It is on a journey to ensure that if it's domain (or a sub-domain thereof) is the RFC5322.From domain in a message, then such a message will pass SPF and/or DKIM authentication checks, and - It is interested in seeing data from receivers about what kind of traffic the receivers are seeing where the domain is used in the RFC5322.From address, perhaps as a way of increasing the rate at which those authentication checks are passing, and - It is providing to DMARC validators some information, in the form of the p= value, that expresses its own level of confidence in how well-implemented its email authentication practices are, with such confidence levels probably roughly approximating: - none - Not at all confident, just starting the process, we know or at least think that some of our mail streams aren't authenticating - quarantine - We think we've got it all locked down, but even a very small risk of bouncing a big campaign is very scary to us, and/or we don't fully trust SPF and DKIM to pass validation checks 100% of the time when they should, and it's better for us and our customer service staff if the mail we originate at least gets delivered to the recipients' spam folders, regardless of the risk of our domain being spoofed. - reject - We've got everything locked down, we're confident in our choices, and if you, Mr. Receiver, accept messages that fail DMARC validation checks and your mailbox holders fall victim to a scam because of it, it's your fault, not ours. Alternatively, 'reject' could also mean 'this domain should never appear as the domain in the RFC5322.From header', but with the same messaging about whose fault it is if messages are accepted and lead to a bad outcome. In the worst case, the domain owner is just checking a box because they think that "publishing a DMARC policy" means "my mail will make it to the inbox". Obviously indirect mail flows, such as mailing lists and forwarding, complicate matters greatly here, as the handling by the intermediary host(s) can and will lead to a higher percentage of authentication failures. The community has attempted to mitigate this problem; RFC5322.From header rewriting, RFC5321.From header rewriting (e.g., SRS), and ARC are among the attempts put forth so far, but none have been deemed The Solution(tm) yet. In my opinion, ARC has promise, because if a message reaches me as a receiver or even intermediary and fails the authentication checks I perform, ARC header sets in the message can tell me whether or not such checks passed at previous hops *if I trust the entities that inserted those ARC header sets*. In an earlier thread, I floated an idea about ARC sealer reputation, but it didn't draw much response, so I'll float it here again in the hopes that it does. The idea is, I believe, simple in concept but complex in execution, and perhaps extraordinarily so, and it requires that a mail handler have a system in place to track reputation, however it defines reputation. We'll let "X" represent an authenticated identity (i.e., a domain that passes an authentication check) and "Y" represent the ARC Sealer identity; my idea would work something like this: - The receiver has in its reputation system already historical data about direct mail flows where X was an authenticated identity, establishing X's reputation with the receiver - ARC header sets record the identities used in authentication checks at a given hop, and the purported results of those checks - For messages arriving with ARC header sets sealed by Y, with X as an authenticated identity in that header set: - If such messages earn a reputation for X that is consistent with that earned by X's direct mail flow, then Y builds a reputation as a trustworthy sealer. It doesn't matter whether X's reputation is good or bad, only that mail seen through the indirect flow has a reputation that is consistent with mail seen through direct flow. - If such messages earn a reputation for X that is inconsistent with that earned by X's direct mail flow, then Y might build a reputation as a non-trustworthy sealer. Now, there are a number of what-ifs here with the latter scenario, chief among them "What if X's mail has a better reputation with an indirect flow than it does with a direct flow?" and I haven't worked those out yet. However, the larger point for me is that if X's mail is functionally the same, reputationally, regardless of whether it arrives by direct or indirect mail flow, then that is evidence that the ARC sealer (Y) can be trusted. Of course X is just one data point in Y's reputation; all authenticated identities that Y records in ARC header sets would play into Y's reputation over time, and yeah, it's complicated. Anyway, I've wandered far afield from your initial query, and though I attempted to address it, I apologize in advance for my loquaciousness. -- *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. --00000000000016dfde05b682df86 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Mon, Dec 14, 2020 at 10:36 PM Michael = Thomas <mike@mtcc.com> wrote:

On 12/14/20 7:26 PM, Douglas Foster wrote:
>
> But what I am trying to figure out is under what circumstances a DMARC=
> policy can be considered actionable.=C2=A0 Do I conclude that
> "p=3Dquarantine" means "domain is still collecting data= , so results are
> unpredictable"?=C2=A0 =C2=A0Or do I conclude that it means "= Domain is fully
> deployed and failure to validate is a highly suspicious event?"

Yeah, that's why I question whether there is something actionable and <= br> whether this is so much wishful thinking. Somebody did say that they
took action on it (gmail?), but i'm not sure whether that is a good thing or a bad thing. For mailing lists, that would seemingly be a bad
thing, but if you're of the mind that mailing lists are a security bug =
and not a feature that might be contradictory.


I'm not sure there's anything = actionable about DMARC's policy values.

For re= ceivers, attempts at manually tracking which RFC5322.From domains appear in= mail that's authenticated or not with SPF and/or DKIM are ones that ar= e bound to fail due to scaling issues. DMARC provides a solution to this pr= oblem, in that if a domain owner publishes a DMARC policy, the receiver now= has some information=C2=A0that the owner of the RFC5322.From domain may ha= ve an expectation that mail with that=C2=A0domain in the RFC5322.From domai= n might be authenticated in some fashion, using SPF and/or DKIM. The=C2=A0r= eceiver can use that data point, and the data points collected from DMARC v= alidation checks for that message, as part of the sum total of data it uses= =C2=A0to decide its handling of that message. If there is a published DMARC= policy for the RFC5322.From domain, and the receiver so chooses, the recei= ver can also use the p=3D value in that policy as another data point contri= buting to the message handling decision, but the receiver is not compelled = or required to do so (nor is the receiver compelled or required to even per= form DMARC validation checks, or send aggregate and/or failure reports, or = even check for the existence of a DMARC policy record for the RFC5322.From = domain).

For domain owners that publish DMARC poli= cies, the best case is that the owner is announcing to the internet at larg= e that=C2=A0
  • It is on a journey to ensure that if it'= s domain (or a sub-domain thereof) is the RFC5322.From domain in a message,= then such a message will pass SPF and/or DKIM authentication checks, and= =C2=A0
  • It is interested in seeing data from receivers about what ki= nd of traffic the receivers are seeing where the domain is used in the RFC5= 322.From address, perhaps as a way of increasing the rate at which those au= thentication checks are passing, and
  • It is providing to DMARC valid= ators some information, in the form of the p=3D value, that expresses its o= wn level of confidence in how well-implemented its email authentication pra= ctices are, with such confidence levels probably roughly approximating:
    • none - Not at all confident, just starting the process, we know or= at least think that some of our mail streams aren't authenticating
    • quarantine - We think we've got it all locked down, but even a ver= y small risk of bouncing a big campaign is very scary to us, and/or we don&= #39;t fully trust SPF and DKIM to pass validation checks 100% of the time w= hen they should, and it's better for us and our customer service staff = if the mail we originate at least gets delivered to the recipients' spa= m folders, regardless of the risk of our domain being spoofed.
    • reje= ct - We've got everything locked down, we're confident in our choic= es, and if you, Mr. Receiver, accept messages that fail DMARC validation ch= ecks and your mailbox holders fall victim to a scam because of it, it's= your fault, not ours. Alternatively, 'reject' could also mean '= ;this domain should never appear as the domain in the RFC5322.From header&#= 39;, but with the same messaging about whose fault it is if messages are ac= cepted and lead to a bad outcome.
In the worst case, the= domain owner is just checking a box because they think that "publishi= ng a DMARC policy" means "my mail will make it to the inbox"= .

Obviously indirect mail flows, such as mai= ling lists and forwarding, complicate matters greatly here, as the handling= by the intermediary host(s) can and will lead to a higher percentage of au= thentication failures. The community has attempted to mitigate this problem= ; RFC5322.From header rewriting, RFC5321.From header rewriting (e.g., SRS),= and ARC are among the attempts put forth so far, but none have been deemed= The Solution(tm) yet. In my opinion, ARC has promise, because if a message= reaches me as a receiver or even intermediary and fails the authentication= checks I perform, ARC header sets in the message can tell me whether or no= t such checks passed at previous hops *if I trust the entities that inserte= d those ARC header sets*. In an earlier thread, I floated an idea about ARC= sealer reputation, but it didn't draw much response, so I'll float= it here again in the hopes that it does.

The idea= is, I believe, simple in concept but complex in execution, and perhaps ext= raordinarily so, and it requires that a mail handler have a system in place= to track reputation, however it defines reputation. We'll let "X&= quot; represent an authenticated identity (i.e., a domain that passes an au= thentication check) and "Y" represent the ARC Sealer identity; my= idea would work something like this:
  • The receiver has in= its reputation system already historical data about direct mail flows wher= e X was an authenticated identity, establishing X's reputation with the= receiver
  • ARC header sets record the identities used in authenticat= ion checks at a given hop, and the purported results of those checks
    • For messages arriving with ARC header sets sealed by Y, with X as an auth= enticated identity in that header set:
    • If such messages earn a = reputation for X that is consistent with that earned by X's direct mail= flow, then Y builds a reputation as a trustworthy sealer. It doesn't m= atter whether X's reputation is good or bad, only that mail seen throug= h the indirect flow has a reputation that is consistent with mail seen thro= ugh direct flow.
    • If such messages earn a reputation for X that is i= nconsistent with that earned by X's direct mail flow, then Y might buil= d a reputation as a non-trustworthy sealer.
Now, there are a = number of what-ifs here with the latter scenario, chief among them "Wh= at if X's mail has a better reputation with an indirect flow than it do= es with a direct flow?" and I haven't worked those out yet. Howeve= r, the larger point for me is that if X's mail is functionally the same= , reputationally, regardless of whether it arrives by direct or indirect ma= il flow, then that is evidence that the ARC sealer (Y) can be trusted. Of c= ourse X is just one data point in Y's reputation; all authenticated ide= ntities that Y records in ARC header sets would play into Y's reputatio= n over time, and yeah, it's complicated.

A= nyway, I've wandered far afield from your initial query, and though I a= ttempted to address it, I apologize in advance for my loquaciousness.=C2=A0=

--

Todd Her= r | Sr. Technical Program Manager
p: 703.= 220.4153


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

--00000000000016dfde05b682df86-- From nobody Wed Dec 16 04:22: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 042183A0B1D for ; Wed, 16 Dec 2020 04:22:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.199 X-Spam-Level: X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, 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 tU9DrYtrZ4yb for ; Wed, 16 Dec 2020 04:22:07 -0800 (PST) Received: from mail-vs1-xe31.google.com (mail-vs1-xe31.google.com [IPv6:2607:f8b0:4864:20::e31]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A71C53A0B17 for ; Wed, 16 Dec 2020 04:22:07 -0800 (PST) Received: by mail-vs1-xe31.google.com with SMTP id j140so12809467vsd.4 for ; Wed, 16 Dec 2020 04:22:07 -0800 (PST) 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=b74U7enD8Nc259FttDMeEuYcYe3mmWzxgxviku2yVJ4=; b=uNfzG5nn+t3hB+EkXm0Fwon9GiN0XPsDMByMLH4g/1t6i9GwDM/P7yJAemYI95qwT0 DabAjuBTvXgU3gjPZkC36LJo3vnQvj5+x1Rj96duhJdTxYvRJkZA5lUFf2mA/eRvJNXa 9rtS1v6iBBTEhFQ9dwhDRtITrjA1iXS8w6q4vqBYtS0HTgMN+ETjWFmFQic00Tuo/KIg OIddCzV1CYg4+ioXt6uj4QjsVkHih6jLb6T5ezF7GbFldl9Q2rTKUEdFpSWXpNJwgZnM mslwpQ9oPJQ/vbwTGM+h8RQ8bmHosEFLEjtyqDG6yFtennGt1iU9QX3Lv6v14LvkWPEz dp9w== 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=b74U7enD8Nc259FttDMeEuYcYe3mmWzxgxviku2yVJ4=; b=BApfEq4P7e7hOme2Lux8g6BHjcIehmcFbp3r6hKLcrrgxATvainbiUinX1ZRiE1XiR 1IeT2/4Ql0sE/4alJA0P8oS7wXdwQQDjnrpEKPuFMevCUIkgbYWB+nkX/WX/C3IyyGUw EF8b5958WiSEU9xFYf8/kuK24SKP3P7aIhuqnvx/5IkUf/751N76s/BF5msZe9kOWQ1V 6EadFi8XNn9J+WIsxs7zUXqLJOZdeMm1bCjv8ghr4WVc74AfVTdJu39JUVOD4G4B1jT2 NvYNOyApLcGif54mggxv2zHpmvolYFnm7YB4UN2GL6pvFr2PhRNsrasNJ3zmBuJjSyuK p3Xw== X-Gm-Message-State: AOAM5328KZJEIrlodvQnTKczwHBIi9o9VSVMijxmBddw1NVElg5NxY4W gVAMHTZrWKK6Lq5Va92YzDmRecR7t4u8ZCKyhmE= X-Google-Smtp-Source: ABdhPJyCXvns9peiuBTXmkdCriYJ8bZzR/YRBzQSKcVK/YQd8Ulrlin9Jy7+d1EMFKLPJPvOf9t25xsMBfKMDAcwbxA= X-Received: by 2002:a05:6102:227c:: with SMTP id v28mr910800vsd.45.1608121326707; Wed, 16 Dec 2020 04:22:06 -0800 (PST) MIME-Version: 1.0 References: <20201211173722.6B4DF29782C7@ary.qy> <02f786e5-b7cd-9a89-e3e3-73594f3bcda0@mtcc.com> In-Reply-To: From: Douglas Foster Date: Wed, 16 Dec 2020 07:21:55 -0500 Message-ID: To: Todd Herr Cc: IETF DMARC WG Content-Type: multipart/alternative; boundary="0000000000006f276905b693ec9c" Archived-At: Subject: Re: [dmarc-ietf] p=quarantine X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 16 Dec 2020 12:22:15 -0000 --0000000000006f276905b693ec9c Content-Type: text/plain; charset="UTF-8" Thank you Todd. I found this very helpful because it sets appropriately low expectations but also describes a framework that I can envision integrating into my filtering process. Some version of these concepts need to be worked into the bis or BCP document, so that product developers do not continue to implement SPF and DMARC as on-off switches without integration to a local policy system which implements the local reputation database. Your comments about ARC do a better job of articulating its use case than I have read anywhere else. I have some ideas for elaborating them, but I will save them for later, to avoid being reminded that forwarding is off topic. Doug Foster --0000000000006f276905b693ec9c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thank you Todd.=C2=A0 =C2=A0I found this very helpful beca= use it sets appropriately low expectations but also describes a framework t= hat I can envision integrating into my filtering process.

Some version of these concepts need to be worked into the bis or BCP docu= ment, so that product developers do not continue to implement SPF and DMARC= as on-off switches without integration to a local policy system which impl= ements the local reputation database.

Your comment= s about ARC do a better job of articulating its use case than I have read a= nywhere=C2=A0else.=C2=A0 =C2=A0I have some ideas for elaborating them, but = I will save them for later, to avoid being reminded that forwarding is off = topic.

Doug Foster

--0000000000006f276905b693ec9c-- From nobody Thu Dec 17 10:25: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 5043F3A0E67 for ; Thu, 17 Dec 2020 10:25:52 -0800 (PST) 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 93GcPzRLmSX9 for ; Thu, 17 Dec 2020 10:25:51 -0800 (PST) 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 DE0CF3A0E4D for ; Thu, 17 Dec 2020 10:25:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1608229548; bh=OFXYjYD/Kekzd5CFKqbW7KzfN82SN9ujcr9mCk6sDqA=; l=740; h=To:From:Date; b=DCVQ7gBsyuEU9joV3HZikiHhPK/YV7a3FDcWmKgKNrgnKbxOU9tEe+W8e8AwyzArz SJmkUMyquhGZ+/7bVKT6LjoEcCbb0as6vlyzH7UAnSuLqSpP/bE2RMCpTwkTUDPhVF 5ootiYOnrGh6MrVBRRk639w06SsLoRlQenct5MSabSw8ilYMZGBbvwoJHszXc Authentication-Results: tana.it; auth=pass (details omitted) Original-From: Alessandro Vesely 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 00000000005DC026.000000005FDBA2AC.00002D6B; Thu, 17 Dec 2020 19:25:48 +0100 To: dmarc-ietf From: Alessandro Vesely Message-ID: Date: Thu, 17 Dec 2020 19:25:48 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [dmarc-ietf] Ticket #55 - Clarify legal and privacy implications of failure reports X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Dec 2020 18:25:52 -0000 We would like to close this ticket two weeks from now, by the end of the year, so please get on it. The ticket text is just: Make it clear in privacy considerations that failure reports can provide PII well beyond a domain name, and are not sent by most receivers. Currently, the dmarc-failure-reporting draft includes the Privacy Considerations of RFC 7489. They address which kind of privacy policy may conflict with failure reporting. Yet, that section doesn't say what PII is contained in a reported message, except generically mentioning that "These reports may expose sender and recipient identifiers (e.g., RFC5322.From addresses)". Do we need to clarify more? Any lawyers in this WG? Best Ale -- From nobody Thu Dec 17 18:39: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 E41103A0BD4 for ; Thu, 17 Dec 2020 18:39:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.85 X-Spam-Level: X-Spam-Status: No, score=-1.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iecc.com header.b=Jnnmp3Y0; dkim=pass (2048-bit key) header.d=taugh.com header.b=c4u+FvRV Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uy1PKoiw1_LU for ; Thu, 17 Dec 2020 18:39:03 -0800 (PST) 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 447A33A0C4F for ; Thu, 17 Dec 2020 18:39:02 -0800 (PST) Received: (qmail 67090 invoked from network); 18 Dec 2020 02:39: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:mime-version:content-type:content-transfer-encoding:cleverness; s=10610.5fdc1645.k2012; bh=HuI7DihlDF+cEaYXjZpgvUjgBak9OLgJW3k+lcTakzE=; b=Jnnmp3Y02ZI/3AmUy1yGkqtLEW3489WT4wyjDJ99G0dU5o9Qn3j8rsOVkCvW6e6WqQaEzAaPTxWOhNCnO0WwbXG8LihpL85nglhQbpTWPHyVKGw+PFwCFhrzsu9/5goHhBQlIFHdmmImavq74TZPaWMZlK/1jhligkKVNdktH9Y5J74HeUYETYkoOKxNyR3s0wQhEove7YTatQMXXrYUuehuyLCw1uv67RCXkWp4oVEiP97n5yj+PJ38KdqF1ifLrIDi5QSYj7lBto7COl5ajdmv9ZKpjdZU91/WFFjKaZo+ZiGBAkK2Q8PMbgIphb1g4b3hQNEVViOkhLKPGhQNEQ== DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=10610.5fdc1645.k2012; bh=HuI7DihlDF+cEaYXjZpgvUjgBak9OLgJW3k+lcTakzE=; b=c4u+FvRVqAzQvJFaIG2LCTUwl3ElemVjkQFJkp3oszyAK6GGPdawt9EVH4kIICLn/h0+O9NbnlgJgmGfUlGqA+S0eTgpVPBgYNFEu/BCSMfTtImWtfM+FY486k4m4uoSBGyVdNEY0S5mvSv/A/GCksTMalMbbsJdIFL1etwzBbpZo51SIMsr6MkATtWkgWXFamDOWLWOyBRrt3UEds4dM+MGPa5sab5Ex3LFTtr+KsdYs4S0pzqpuRlOJK5aT8uu7bQoL5cwPnLTjurpD/lfp0In1eJHdH+LungM9Zd4EXpgHY1OuPzk3nAB/4dDznA1/2ycRa/2eaqxp1+lIhMOPg== 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; 18 Dec 2020 02:39:01 -0000 Received: by ary.qy (Postfix, from userid 501) id E73B82ACBB2B; Thu, 17 Dec 2020 21:39:00 -0500 (EST) Date: 17 Dec 2020 21:39:00 -0500 Message-Id: <20201218023900.E73B82ACBB2B@ary.qy> From: "John Levine" To: dmarc@ietf.org Cc: vesely@tana.it In-Reply-To: Organization: Taughannock Networks X-Headerized: yes Cleverness: minimal Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] Ticket #55 - Clarify legal and privacy implications of failure reports X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Dec 2020 02:39:05 -0000 In article you write: >We would like to close this ticket two weeks from now, by the end of the year, >so please get on it. > >The ticket text is just: > > Make it clear in privacy considerations that failure reports can provide > PII well beyond a domain name, and are not sent by most receivers. The current text says that, but it should also point out that redaction does not always remove PII. Info about sender or recipient might be encoded in non-obvious places such as the Message-ID or DKIM selectors.* Also, whether we use the current Org domain heuristic or a tree walk to find a higher level DMARC record, there is no way to reliably tell the relationship between a domain publishing the rua or ruf tag and a subdomain being reported. Partly this is the Holy Roman Empire problem, partly the PSL is just incomplete and always will be. >Any lawyers in this WG? The IETF most definitely does not provide legal advice. R's, John * - I've been doing that for ages. Every message gets a unique selector. From nobody Fri Dec 18 00: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 E6CFB3A1181 for ; Fri, 18 Dec 2020 00:58:26 -0800 (PST) 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, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 kq83dhladgfV for ; Fri, 18 Dec 2020 00:58:24 -0800 (PST) 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 A3F103A1179 for ; Fri, 18 Dec 2020 00:58:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1608281900; bh=8aYZ5gwMnsDJpw29TdfDqmflEdTyivpPOk85poIoJPA=; l=250; h=To:References:From:Date:In-Reply-To; b=BGiSQWDPeJqQCYDm6tTRYWSkQtmuFb2U0TzMZ6YoMKsyDB25puPgzKXV5cYobs6K1 Lk4z8N/jI7Oc2zy+rXbpphatkK1jBsqmUJmFJKfORKAUPWvRsxA+SqH7tHrBppsw4w BGH/K24xrcwlHQjRMJ02M85JspcuLUnZwDgTlFc8/QyH50BPzPlFdu1mbns8W Authentication-Results: tana.it; auth=pass (details omitted) Original-From: Alessandro Vesely 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.000000005FDC6F2C.000046D4; Fri, 18 Dec 2020 09:58:20 +0100 To: dmarc@ietf.org References: <20201209000447.205FF2938F97@ary.qy> <6a4335a-a043-b5b5-1e36-1debae7e7a9a@taugh.com> <62961791-56dd-506c-b99a-098ed0ee6ca2@gmail.com> From: Alessandro Vesely Message-ID: <20fdea26-dcd9-4757-b1ee-d97cef891cbe@tana.it> Date: Fri, 18 Dec 2020 09:58:20 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: <62961791-56dd-506c-b99a-098ed0ee6ca2@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] Ticket #28 - Failure report mail loops X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Dec 2020 08:58:27 -0000 On Wed 09/Dec/2020 18:22:04 +0100 Dave Crocker wrote: > On 12/9/2020 7:23 AM, John R Levine wrote: >> No.  This is not a problem.  There is nothing to fix.  Please close this ticket. > > +1 Fair enough. Ticket closed. Best Ale -- From nobody Fri Dec 18 09:53: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 11A0F3A0B32 for ; Fri, 18 Dec 2020 09:53:51 -0800 (PST) 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, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 K4MBMuBONyZq for ; Fri, 18 Dec 2020 09:53:49 -0800 (PST) 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 8BC5C3A0957 for ; Fri, 18 Dec 2020 09:53:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1608314025; bh=SQPuWRkT5MV2PdNc20xks5Y8wDvpMmJ76F/K3swsLj0=; l=1973; h=To:References:From:Date:In-Reply-To; b=CjMxbEPAp8aUZDabZGMWxGvUVUoruSO2iFtjU/q5jlRppTCFsRrRNwJmg6xc3ZM7v xR9t1KlNNHmvXVn6OiejL51CCCsUAS0yW+VGzLRTeJLtvM48IU6evwOZ6Oi1lZdkgq qfk03GRvhxQbjyXxNYgWHBjSqImgiYg/d4RLnhKy3MG48hBjY8J+G8Km1lP9i Authentication-Results: tana.it; auth=pass (details omitted) Original-From: Alessandro Vesely 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 00000000005DC0CD.000000005FDCECA9.00000586; Fri, 18 Dec 2020 18:53:45 +0100 To: John Levine , dmarc@ietf.org References: <20201218023900.E73B82ACBB2B@ary.qy> From: Alessandro Vesely Message-ID: <4a43ffaa-3987-c892-cce7-56f18888cdf5@tana.it> Date: Fri, 18 Dec 2020 18:53:45 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: <20201218023900.E73B82ACBB2B@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] Ticket #55 - Clarify legal and privacy implications of failure reports X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Dec 2020 17:53:51 -0000 On Fri 18/Dec/2020 03:39:00 +0100 John Levine wrote: > In article you write: >> We would like to close this ticket two weeks from now, by the end of the year, >> so please get on it. >> >> The ticket text is just: >> >> Make it clear in privacy considerations that failure reports can provide >> PII well beyond a domain name, and are not sent by most receivers. > > The current text says that, but it should also point out that > redaction does not always remove PII. Info about sender or recipient > might be encoded in non-obvious places such as the Message-ID or DKIM > selectors.* Info which is encoded in such a way that only the sender can understand rises no PII concern, IMHO. A sender could cache sent messages and devise how to encode the corresponding filenames in DKIM selectors. Reporting just the failed signature would leak the whole message by reference. So what? > Also, whether we use the current Org domain heuristic or a tree walk > to find a higher level DMARC record, there is no way to reliably tell > the relationship between a domain publishing the rua or ruf tag and a > subdomain being reported. Partly this is the Holy Roman Empire > problem, partly the PSL is just incomplete and always will be. Right. A user can use a submission server which is trusted not to relay messages to third parties. Yet, ruf= can point to a completely different environment. By reporting failures (which could be each and every message) a report producer can be of service to covert communication tracking. To avoid that risk, one can send just the header, and redact it appropriately. Should the spec give practical advice about how to do that? >> Any lawyers in this WG? > > The IETF most definitely does not provide legal advice. That sounds more like a bug than a feature. We should at least check that any advice given is legally sound. Best Ale -- From nobody Fri Dec 18 12:05: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 5866C3A0762 for ; Fri, 18 Dec 2020 12:05:49 -0800 (PST) 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 (2048-bit key) header.d=iecc.com header.b=V0oBgJCR; dkim=pass (2048-bit key) header.d=taugh.com header.b=brEZqhz6 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iH0Y15rQieCQ for ; Fri, 18 Dec 2020 12:05:46 -0800 (PST) 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 306A63A074E for ; Fri, 18 Dec 2020 12:05:45 -0800 (PST) Received: (qmail 5763 invoked from network); 18 Dec 2020 20:05:43 -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=167b.5fdd0b97.k2012; i=johnl-iecc.com@submit.iecc.com; bh=4RU218DIC8oS+2wBSjSxWWp2Qti1b7mMm6l+CIhP9p0=; b=V0oBgJCR6zJ3vV+1oTGQJaqRVh3vy5DYw0wAX2q0Z4KU0Q/lAhwMPWzv//HyS7T2/J9aNQaOCeTxVI4V2wsLS0ATMDMUdypDJmtc1nskKb4uNhqTg1dOcg2i81Rtbb6Ccb8aTm/HPLCIh0nHyLzJ/z63q5dC3DPAuoOsqnyYlo/5SSTuJ0iRkpIwxVigpD4tXbxMO+noMZOKbRQ+r+9DZgZ8ITtN6voVcBILOfaaAwykj+B81rAQjasPBX9Nwu96PZ65EViw92hicpmxULIzzBCCq2YjWyAikgm4+VicnL2YFXLX3cB5t7NrIiqT9U8YRF8gHu4V6kFZTDpyi+6Teg== 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=167b.5fdd0b97.k2012; olt=johnl-iecc.com@submit.iecc.com; bh=4RU218DIC8oS+2wBSjSxWWp2Qti1b7mMm6l+CIhP9p0=; b=brEZqhz6deAagQlqxnde0c2GAmYplT6SdJgMZwwNX9uG3x0IYLAf+YmmuLcggLJPUlL7QjebQ6epO6+LSOOOYlJe6D0KETpsx3mtFz7wYaCVdk80OgVpHHgrx58nLo1CgoCUjTtt1oGmCtsb5dky/rNq5vblBuGGnreDB8eY2yfFqLjrb6KL8EWq0Ue6QMRLvfBNLnfsGdnVS3Z1bl5y5yYycVuOezojHeIEwizOm2o53EZmJEkNLne3kePoZoxZKDLimgGnEbTX4lamsvt4Tj/anf509VAJlhTRJCg/sUiBZrNu2B8fdML7mKUNeqS/rFw7TNqmcxmDBGPvllCe2A== Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPSA (TLS1.3 ECDHE-RSA AES-256-GCM AEAD, johnl@iecc.com) via TCP6; 18 Dec 2020 20:05:43 -0000 Date: 18 Dec 2020 15:05:43 -0500 Message-ID: <39125012-e356-d62d-36fd-a7ff25a9f59f@taugh.com> From: "John R Levine" To: "Alessandro Vesely" , dmarc@ietf.org In-Reply-To: <4a43ffaa-3987-c892-cce7-56f18888cdf5@tana.it> References: <20201218023900.E73B82ACBB2B@ary.qy> <4a43ffaa-3987-c892-cce7-56f18888cdf5@tana.it> MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII Archived-At: Subject: Re: [dmarc-ietf] Ticket #55 - Clarify legal and privacy implications of failure reports X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Dec 2020 20:05:49 -0000 > Info which is encoded in such a way that only the sender can understand rises > no PII concern, IMHO. A sender could cache sent messages and devise how to > encode the corresponding filenames in DKIM selectors. Reporting just the > failed signature would leak the whole message by reference. So what? Now he knows which forwarded recipients are talking with his users. >> Also, whether we use the current Org domain heuristic or a tree walk >> to find a higher level DMARC record, there is no way to reliably tell >> the relationship between a domain publishing the rua or ruf tag and a >> subdomain being reported. Partly this is the Holy Roman Empire >> problem, partly the PSL is just incomplete and always will be. > > Right. A user can use a submission server which is trusted not to relay > messages to third parties. Yet, ruf= can point to a completely different > environment. No, that's not what I was talking about. I am the registry for someplace.ny.us, and the county government is co.someplace.ny.us. I get all of the DMARC reports for the county's mail. Oops. I'm not being hypothetical here. > To avoid that risk, one can send just the header, and redact it > appropriately. Should the spec give practical advice about how to do that? Since it doesn't solve the problem, no. >>> Any lawyers in this WG? >> >> The IETF most definitely does not provide legal advice. > > That sounds more like a bug than a feature. We should at least check that > any advice given is legally sound. There are 195 countries in the world, and many like the US have states or provinces with different legal systems. Legally sound where? R's, John From nobody Fri Dec 18 13:55: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 3CD0F3A0990 for ; Fri, 18 Dec 2020 13:55:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.748 X-Spam-Level: X-Spam-Status: No, score=-1.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mtcc.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 299MdHas0NJA for ; Fri, 18 Dec 2020 13:54:58 -0800 (PST) Received: from mail-pj1-x1029.google.com (mail-pj1-x1029.google.com [IPv6:2607:f8b0:4864:20::1029]) (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 A9B5F3A097E for ; Fri, 18 Dec 2020 13:54:58 -0800 (PST) Received: by mail-pj1-x1029.google.com with SMTP id m5so2074321pjv.5 for ; Fri, 18 Dec 2020 13:54:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mtcc.com; s=fluffulence; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=5Nux3lbXs1NWXD2gH1/3SVnCZsG8ioB9BvpMgANPGQs=; b=RYbRPnMPMO3B10MQ+TGbzEO4T73MuPstgNaUv382XiX+qaYJUq5M22onXUE6TkC5Ue px5NE6go3Z3fH+8iK6OCC4Kwmwpkj2hY0aSgUda4PXbK7VXr9JHDORr94oNhFYu9Fm7v +xMEnZY22NsCCnt/oFdFjjmNkTfD6mjGu++21YvD9ZqEkQRD0JtKHV5CZbuS7EmmoNx5 fM0OeSLISCVyywDtA0Xp4t8nR4/PUXTknF/6P1EWrnvBnRLnWUPC2nwHDA+odjhcLam0 l719aVbdtk2Qhdh8hR+C2Md1gjjk9W1WZMHw4WjhVCliQI1l0yfZ5Aw4EjU2HjERRBY7 tDiA== 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=5Nux3lbXs1NWXD2gH1/3SVnCZsG8ioB9BvpMgANPGQs=; b=qg+eZYrhdtcOhYDCAD/ZMg947u5xfNY70Rb1eF0wKlv/+kAuzX9mZNXvUOYPk6OmHN rZo7lpxNGbNFGZ5UuYwVJsChpPfmKxELqKN5gp2VCvV2r40ZEWj5AF5SQ4kavlxrur3Z iSxJGNydD4N/o3Wy23UqqRDqN6u/qFeDDnpf3yLUC4iJNGK/T+QNUpR3mkZ0Q0WaieFq tO2cV2nOw1pb+Xo9LoKXsS7wd32KtjSvYDAWxvEXyXpJd2blu2pEZW/zbD44LOm8QMdI Dj+nTY83IdrAHbJC3aS/a8zLnGf9Oih8m8epfH9aPuBGqrsJ4t95PfiZp7jUeXQ1xsp2 2yxw== X-Gm-Message-State: AOAM532uT8IlGNX+ruQs2sGJU9VDXoRTzvW+JueEUBdbtDVBE9nCDFjn 9gY9dosJhEP5V7YnhHGH0n1zLgFODnqbtg== X-Google-Smtp-Source: ABdhPJzhKsoSPDBWJIvYcbXrl4IDRQoqB3dobLMPVWfvir3wSWpeNmydkfXlu8ZIEeccAp7R+JJmWw== X-Received: by 2002:a17:90b:203:: with SMTP id fy3mr6357046pjb.231.1608328497493; Fri, 18 Dec 2020 13:54:57 -0800 (PST) Received: from mike-mac.lan ([107.182.37.0]) by smtp.gmail.com with ESMTPSA id e5sm8774307pjs.0.2020.12.18.13.54.55 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 18 Dec 2020 13:54:56 -0800 (PST) To: dmarc@ietf.org References: <20201211173722.6B4DF29782C7@ary.qy> <02f786e5-b7cd-9a89-e3e3-73594f3bcda0@mtcc.com> From: Michael Thomas Message-ID: Date: Fri, 18 Dec 2020 13:54:54 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------F4D3808F3F668CEF43F9AA66" Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] p=quarantine X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 18 Dec 2020 21:55:00 -0000 This is a multi-part message in MIME format. --------------F4D3808F3F668CEF43F9AA66 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 12/15/20 8:01 AM, Todd Herr wrote: > > I'm not sure there's anything actionable about DMARC's policy values. you mean p=quarantine, or p=* in general? > Obviously indirect mail flows, such as mailing lists and forwarding, > complicate matters greatly here, as the handling by the intermediary > host(s) can and will lead to a higher percentage of authentication > failures. The community has attempted to mitigate this problem; > RFC5322.From header rewriting, RFC5321.From header rewriting (e.g., > SRS), and ARC are among the attempts put forth so far, but none have > been deemed The Solution(tm) yet. In my opinion, ARC has promise, > because if a message reaches me as a receiver or even intermediary and > fails the authentication checks I perform, ARC header sets in the > message can tell me whether or not such checks passed at previous hops > *if I trust the entities that inserted those ARC header sets*. In an > earlier thread, I floated an idea about ARC sealer reputation, but it > didn't draw much response, so I'll float it here again in the hopes > that it does. > We've always been able to check the reputation of lists that resign the message. The reputation is the previously (un)solved problem. Mike > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc --------------F4D3808F3F668CEF43F9AA66 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit


On 12/15/20 8:01 AM, Todd Herr wrote:

I'm not sure there's anything actionable about DMARC's policy values.

you mean p=quarantine, or p=* in general?


Obviously indirect mail flows, such as mailing lists and forwarding, complicate matters greatly here, as the handling by the intermediary host(s) can and will lead to a higher percentage of authentication failures. The community has attempted to mitigate this problem; RFC5322.From header rewriting, RFC5321.From header rewriting (e.g., SRS), and ARC are among the attempts put forth so far, but none have been deemed The Solution(tm) yet. In my opinion, ARC has promise, because if a message reaches me as a receiver or even intermediary and fails the authentication checks I perform, ARC header sets in the message can tell me whether or not such checks passed at previous hops *if I trust the entities that inserted those ARC header sets*. In an earlier thread, I floated an idea about ARC sealer reputation, but it didn't draw much response, so I'll float it here again in the hopes that it does.

We've always been able to check the reputation of lists that resign the message. The reputation is the previously (un)solved problem.

Mike


_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
--------------F4D3808F3F668CEF43F9AA66-- From nobody Fri Dec 18 16:04: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 BB7883A0836 for ; Fri, 18 Dec 2020 16:04:12 -0800 (PST) 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 V5cFexfIkQTb for ; Fri, 18 Dec 2020 16:04:10 -0800 (PST) Received: from mail-vs1-xe31.google.com (mail-vs1-xe31.google.com [IPv6:2607:f8b0:4864:20::e31]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7679F3A082F for ; Fri, 18 Dec 2020 16:04:10 -0800 (PST) Received: by mail-vs1-xe31.google.com with SMTP id s85so2299237vsc.3 for ; Fri, 18 Dec 2020 16:04:10 -0800 (PST) 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=Bqspd++qc3RTW10nJNpd/Q6gjwg7Zv+g72glfJQOf34=; b=Bi86tadTTKL93F1DjQdMMmFMLBc1VNuixgZ7NY1keSiV0Ts9ALABwxImC6n2ufALUL CUyTmoEoDunK8v5kLwqw2DzPUb7KAycRp3SxRAptxcu+JGNmQbX++OD8nkhSw0gIMrMG s4RUywDwcKkNbE/YfcPZ5UJSz02wFTjQdLnsdMDEkIt/3DjSR8WOQflgwgDo+zquxh9A ijXb+mHTTIZg/O97jP+n9vVxgix2L/DnZoHXw4rttbC7THP+EtRa9RombkCWV+wId/zr G8HEFauhtFavBZeR78wsT5Ybl0v4Ig1ny859F2mpT/6DmON8RIJQRrnFoYfx8WOar6zi zxKQ== 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=Bqspd++qc3RTW10nJNpd/Q6gjwg7Zv+g72glfJQOf34=; b=eDXlalhCTQoFnWESBhzhHW/xZ2qJ+ZADv1zO4yGwfNOi7ULGrt675hQhU9+RwnuDQh S5rA+yNm5kRsqtqszwiCJ7XHLdpbotTw2O7BIVowN7wtSpuujF4o+zRX+lNEzf4U0vDm Hin1TK8HSwu6sR2CEYzfjIeMG5oqxvA/r3FUFDYC8blQuuPsCOfKJflS6kcDd1TUY8Lo WhFdMDHrQlGPboYSIOQhkI/yugSlObwVn2V14RV4kwHc/iL+YwpdJsAJuvpKFzieTHzP aQcQRox2dX6cbldNkwaB+bL0w7a1QA821Y5P1OhO5YQNQPCyea6I7PQDwk7su26jg9PE 5StQ== X-Gm-Message-State: AOAM532J11R5hmhhgLcvva+/FLj+TGZlNVQRqse19+mMnIPPU4/MrTfz nBXJDeKlDs7KyPYD1d2CNmi2mYV7cKBT7g5g7+yA7vPXqJQ= X-Google-Smtp-Source: ABdhPJwLzXOQIwIehAlr03xIDzzpZqoAgC98xccyO9NRFVcjtdXgEAVj3ICx3tm1QmIYb3j9z40zLbqMgJqUIbX/MQ0= X-Received: by 2002:a05:6102:4b6:: with SMTP id r22mr6941812vsa.41.1608336249051; Fri, 18 Dec 2020 16:04:09 -0800 (PST) MIME-Version: 1.0 References: <20201218023900.E73B82ACBB2B@ary.qy> <4a43ffaa-3987-c892-cce7-56f18888cdf5@tana.it> <39125012-e356-d62d-36fd-a7ff25a9f59f@taugh.com> In-Reply-To: <39125012-e356-d62d-36fd-a7ff25a9f59f@taugh.com> From: Seth Blank Date: Fri, 18 Dec 2020 16:03:58 -0800 Message-ID: To: IETF DMARC WG Cc: Alessandro Vesely , John Levine Content-Type: multipart/alternative; boundary="000000000000cdee5005b6c5f654" Archived-At: Subject: Re: [dmarc-ietf] Ticket #55 - Clarify legal and privacy implications of failure reports X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Dec 2020 00:04:13 -0000 --000000000000cdee5005b6c5f654 Content-Type: text/plain; charset="UTF-8" I think the general point is that when DMARC was originally written, there was a general expectation that forensic reports were essential to get domains to authenticate properly, and would be generally provided. We now know that forensic reports come from only a handful of places, mostly due to PII considerations due to how reports are redacted in practice. A privacy consideration should say such a thing, specifically clarify what may be in a report that could be categorized as PII even after intended redaction, but refrain from legal advice. Seth, with schrodinger's hat On Fri, Dec 18, 2020 at 12:05 PM John R Levine wrote: > > Info which is encoded in such a way that only the sender can understand > rises > > no PII concern, IMHO. A sender could cache sent messages and devise how > to > > encode the corresponding filenames in DKIM selectors. Reporting just > the > > failed signature would leak the whole message by reference. So what? > > Now he knows which forwarded recipients are talking with his users. > > >> Also, whether we use the current Org domain heuristic or a tree walk > >> to find a higher level DMARC record, there is no way to reliably tell > >> the relationship between a domain publishing the rua or ruf tag and a > >> subdomain being reported. Partly this is the Holy Roman Empire > >> problem, partly the PSL is just incomplete and always will be. > > > > Right. A user can use a submission server which is trusted not to relay > > messages to third parties. Yet, ruf= can point to a completely > different > > environment. > > No, that's not what I was talking about. I am the registry for > someplace.ny.us, and the county government is co.someplace.ny.us. I get > all of the DMARC reports for the county's mail. Oops. I'm not being > hypothetical here. > > > To avoid that risk, one can send just the header, and redact it > > appropriately. Should the spec give practical advice about how to do > that? > > Since it doesn't solve the problem, no. > > >>> Any lawyers in this WG? > >> > >> The IETF most definitely does not provide legal advice. > > > > That sounds more like a bug than a feature. We should at least check > that > > any advice given is legally sound. > > There are 195 countries in the world, and many like the US have states or > provinces with different legal systems. Legally sound where? > > R's, > John > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > -- *Seth Blank* | VP, Standards and New Technologies *e:* seth@valimail.com *p:* 415.273.8818 This email and all data transmitted with it contains confidential and/or proprietary information intended solely for the use of individual(s) authorized to receive it. If you are not an intended and authorized recipient you are hereby notified of any use, disclosure, copying or distribution of the information included in this transmission is prohibited and may be unlawful. Please immediately notify the sender by replying to this email and then delete it from your system. --000000000000cdee5005b6c5f654 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I think the general point is that when DMARC was originall= y written, there was a general expectation that forensic reports were essen= tial to get domains to authenticate properly, and would be generally provid= ed.

We now know that forensic reports come from only a h= andful of places, mostly due to PII considerations due to how reports are r= edacted in practice.

A privacy consideration shoul= d say such a thing, specifically clarify what may be in a report that could= be categorized as PII even after intended redaction, but refrain from lega= l advice.

Seth, with schrodinger's hat

On= Fri, Dec 18, 2020 at 12:05 PM John R Levine <johnl@taugh.com> wrote:
> Info which is encoded in such a way that only = the sender can understand rises
> no PII concern, IMHO.=C2=A0 A sender could cache sent messages and dev= ise how to
> encode the corresponding filenames in DKIM selectors.=C2=A0 Reporting = just the
> failed signature would leak the whole message by reference.=C2=A0 So w= hat?

Now he knows which forwarded recipients are talking with his users.

>> Also, whether we use the current Org domain heuristic or a tree wa= lk
>> to find a higher level DMARC record, there is no way to reliably t= ell
>> the relationship between a domain publishing the rua or ruf tag an= d a
>> subdomain being reported. Partly this is the Holy Roman Empire
>> problem, partly the PSL is just incomplete and always will be.
>
> Right.=C2=A0 A user can use a submission server which is trusted not t= o relay
> messages to third parties.=C2=A0 Yet, ruf=3D can point to a completely= different
> environment.

No, that's not what I was talking about.=C2=A0 I am the registry for som= eplace.ny.us, and the county government is co.someplace.ny.us.=C2= =A0 I get
all of the DMARC reports for the county's mail.=C2=A0 Oops.=C2=A0 I'= ;m not being
hypothetical here.

> To avoid that risk, one can send just the header, and redact it
> appropriately. Should the spec give practical advice about how to do t= hat?

Since it doesn't solve the problem, no.

>>> Any lawyers in this WG?
>>
>> The IETF most definitely does not provide legal advice.
>
> That sounds more like a bug than a feature.=C2=A0 We should at least c= heck that
> any advice given is legally sound.

There are 195 countries in the world, and many like the US have states or <= br> provinces with different legal systems.=C2=A0 Legally sound where?

R's,
John

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


--

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


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

--000000000000cdee5005b6c5f654-- From nobody Sat Dec 19 02:24: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 4340C3A0FE2 for ; Sat, 19 Dec 2020 02:24:50 -0800 (PST) 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, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 bhqeqQiPIc4l for ; Sat, 19 Dec 2020 02:24:49 -0800 (PST) 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 D44AB3A0FDE for ; Sat, 19 Dec 2020 02:24:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1608373485; bh=g6XQTRuzKvXxk1/hesL6TCpfzRdTqHA0j/s+rf0Ot3w=; l=1323; h=To:References:From:Date:In-Reply-To; b=A/5iD3tCxF/+yzcZBK+GyYW3zgtdhfYNBl2DeQof9Z0rpJB2Hcn38ZCRxqC0jV2Au /UuH7meOFl7ECXA2EfvosKa21TpTG11knzanmIJq4xvbDinF0UZlNE1jGx5OhoIm1y nEa7mX4Kt850jo6r0gZgRMFKeNn3PEHU1k5y2fg0k8iHg7Rz2ZyNDjyakXdk2 Authentication-Results: tana.it; auth=pass (details omitted) Original-From: Alessandro Vesely Received: from [172.25.197.111] (pcale.tana [172.25.197.111]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLS1.3, 128bits, ECDHE_RSA_AES_128_GCM_SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC0CE.000000005FDDD4EC.0000207C; Sat, 19 Dec 2020 11:24:44 +0100 To: dmarc@ietf.org References: <20201211173722.6B4DF29782C7@ary.qy> <02f786e5-b7cd-9a89-e3e3-73594f3bcda0@mtcc.com> From: Alessandro Vesely Message-ID: <1e61f7c4-c6d2-5dab-dfc7-f1fd740e1d0d@tana.it> Date: Sat, 19 Dec 2020 11:24:44 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] p=quarantine X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 19 Dec 2020 10:24:50 -0000 On Fri 18/Dec/2020 22:54:54 +0100 Michael Thomas wrote: >> In my opinion, ARC has promise, because if a message reaches me as a receiver >> or even intermediary and fails the authentication checks I perform, ARC >> header sets in the message can tell me whether or not such checks passed at >> previous hops *if I trust the entities that inserted those ARC header sets*. >> In an earlier thread, I floated an idea about ARC sealer reputation, but it >> didn't draw much response, so I'll float it here again in the hopes that it >> does. >> > We've always been able to check the reputation of lists that resign the > message. The reputation is the previously (un)solved problem. Yesterday 34 new domains —domains I never heard of before— sent 35 messages to my MX. I count identifiers. Some of them are subdomains of known domains, so they might inherit their parent's reputation. Several others, however, are new organizational domains. I'm just looking at the first 8, and none of them looks like a throw-away, freshly registered domain. Now my tiny MX stores 115,225 domains total. And I have no idea how I could add a trust-ARC-seals boolean field to each domain record. Except for a few gigantic mailbox providers, I'd say the reputation problem is not quite solved. Best Ale -- From nobody Sat Dec 19 08:48: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 723693A0BB0 for ; Sat, 19 Dec 2020 08:48:55 -0800 (PST) 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, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 Ne9y1ZHjwBba for ; Sat, 19 Dec 2020 08:48:54 -0800 (PST) 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 5F57D3A0BA4 for ; Sat, 19 Dec 2020 08:48:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1608396531; bh=txCnWhU8L73BF1xwq0dvNzEoQSc/lrYrPvUeybmXyJg=; l=1159; h=To:References:From:Date:In-Reply-To; b=AwmXPTsLexcYrHautNxYSTNM8l5hyXXXZ0vWP4KofvIYOQnvxCYGpfUYvzVA+DOg/ ENffdRDO/ec5lQP4iG5iF3oOsv2aLseCK2VJhIlWi5Kaih/iBcNsS8Uo6zXwH72cZt /XX8wKrhPBMa8BlkoOrYi4nSRtcSob7ZYXIf3HEC0B0cB/JXfwG4A1o1bQ7ok Authentication-Results: tana.it; auth=pass (details omitted) Original-From: Alessandro Vesely 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 00000000005DC07E.000000005FDE2EF3.0000469B; Sat, 19 Dec 2020 17:48:51 +0100 To: Seth Blank , IETF DMARC WG , John Levine References: <20201218023900.E73B82ACBB2B@ary.qy> <4a43ffaa-3987-c892-cce7-56f18888cdf5@tana.it> <39125012-e356-d62d-36fd-a7ff25a9f59f@taugh.com> From: Alessandro Vesely Message-ID: <754690b7-6624-4cc6-66e1-62438b32cdd4@tana.it> Date: Sat, 19 Dec 2020 17:48:50 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Ticket #55 - Clarify legal and privacy implications of failure reports X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Dec 2020 16:48:56 -0000 On Sat 19/Dec/2020 01:03:58 +0100 Seth Blank wrote: > > A privacy consideration should say such a thing, specifically clarify what > may be in a report that could be categorized as PII even after intended > redaction, but refrain from legal advice. As John pointed out, an IP address can be classed as personal data in a country and not in another. It is hard to tell what data could be PII while refraining from legal considerations. Anyway, email addresses seem to be PII under any legislation. Indeed, that's the only piece of data mentioned by RFC 6590. (Hence I guess one should redact also From:, Jesse's point for ticket #61 notwithstanding.) Yet, spam complaints seem to be sent w/o redaction. I confess I wouldn't know how to carry out an "intended redaction". I cannot recall any useful redacting recommendation for email messages. Most "practical" guides recommend to print them, carefully redact addresses, phone numbers and the like, then scan the result and send the image. Non so practical for a mail filter daemon. I read Outlook has a message redaction feature. I'd be curious about what does that deliver. Best Ale -- From nobody Sat Dec 19 11:50: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 CA56F3A0EBE for ; Sat, 19 Dec 2020 11:50:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.85 X-Spam-Level: X-Spam-Status: No, score=-1.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iecc.com header.b=uyGP138I; dkim=pass (2048-bit key) header.d=taugh.com header.b=YEEzIxA/ Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wWFgHo_NhlS1 for ; Sat, 19 Dec 2020 11:49:58 -0800 (PST) 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 1492E3A0EC1 for ; Sat, 19 Dec 2020 11:49:57 -0800 (PST) Received: (qmail 24393 invoked from network); 19 Dec 2020 19:49: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:mime-version:content-type:content-transfer-encoding:cleverness; s=5f46.5fde5963.k2012; bh=npMiaNMddYgQYDkyf1Pr7SdFYZmIJG7oK4NJxjl+PKk=; b=uyGP138IC6nHjyx9v+C1z8ydLeY+4eKPw12ihjXclAzE5aaOX7F/mkAfFRxtKIF7XSH0XWjkWpr/jNE1hux5qAatEwXbE557SOUMUVMUSH+27Kz1sd1KXBCIMTyUqRfBbHFpeUogzju+NeP/eSrgT5l3xE5LMUm9HZmx5TL8XTHbFFmWrnGft7kBNRIBIHFdWfz7LyF02oFAOUC5VjpDKeLE0srgSwjEkK8epZBWf0SahceL2X2EZQfyofWf4bBxalxkDUk0kQw58CaVWDLZufUAnjV0Dy+fxAfyw64WjoHsqLfDaaYR9EMbtVCDqiGJY6itQ+hkfmYY6J3abNd8XQ== DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=5f46.5fde5963.k2012; bh=npMiaNMddYgQYDkyf1Pr7SdFYZmIJG7oK4NJxjl+PKk=; b=YEEzIxA/07tFpFH/Wa6Jl0NMcgcLCYmAcBhcMJUpb51dZdR12pTra6VD63d9coh5BgRvxI8yWNObhJP4JrjHxHbHghfuz3BkFzAeUP1/PiIQtc7NjkehAcn3y1l30p/Py1+xOmA9oAVIQoq5oUi0yNo40dm7w2QpwiJPSiLQv1TVNOUccVAN53dkM2PYMNd+vdjM35BE+LnG+wk87jeTjo4bNXbQFyhqRaeOCA+rt8TWX9/nQN2CdqjDBaVKLJHPr2PV2RyrZYkb6+y9Pv/WzPLGPLxPSOEnaegSIaXitfR4vPUHa1iVAvxSvX5vAua9p/less9yJ8iXRIPOdmFg5A== 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; 19 Dec 2020 19:49:55 -0000 Received: by ary.qy (Postfix, from userid 501) id BF87E2ADF1FB; Sat, 19 Dec 2020 14:49:54 -0500 (EST) Date: 19 Dec 2020 14:49:54 -0500 Message-Id: <20201219194954.BF87E2ADF1FB@ary.qy> From: "John Levine" To: dmarc@ietf.org Cc: vesely@tana.it In-Reply-To: <1e61f7c4-c6d2-5dab-dfc7-f1fd740e1d0d@tana.it> Organization: Taughannock Networks X-Headerized: yes Cleverness: minimal Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] ARC vs p=quarantine X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 19 Dec 2020 19:50:01 -0000 In article <1e61f7c4-c6d2-5dab-dfc7-f1fd740e1d0d@tana.it> you write: >Now my tiny MX stores 115,225 domains total. And I have no idea how I could >add a trust-ARC-seals boolean field to each domain record. You wouldn't. Only a small fraction of those domains send enough forwarded mail to be worth worrying about. We know we need some sort of shared list of plausible forwarders but I would be amazed if it were anything like 115K domains. R's, John From nobody Sat Dec 19 11:52: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 096B33A0EC3 for ; Sat, 19 Dec 2020 11:52:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.85 X-Spam-Level: X-Spam-Status: No, score=-1.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iecc.com header.b=VKlEww8W; dkim=pass (2048-bit key) header.d=taugh.com header.b=EbiwZdwL Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00Y5oiDVPe0m for ; Sat, 19 Dec 2020 11:52:07 -0800 (PST) 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 2E4A53A0EC1 for ; Sat, 19 Dec 2020 11:52:06 -0800 (PST) Received: (qmail 24811 invoked from network); 19 Dec 2020 19:52:06 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=60e9.5fde59e6.k2012; bh=i09HoYAthITji9s8YuJcDUzqvnReWHZujK0OXptt0t0=; b=VKlEww8Wgi2yAQzDKsPbZNNGsip1BUb0aCRHF8CGdUBVXWlbfZeoBBdqratJ/L2YfAlFOc1K0k6F/dnIIIdWA81dGev1T8ZVOjxMtwuS0WaL5fiEHBCzoqhmHRNR++s9yAFvulccHp9TBfUWlZMQAlukYqSXEENRP0so0QNUHKYvUZ9yWP5iEOR7ElW8MGLaU0rkcM2sti9xc3afI03DFddaGE8QbFiOHA4B2T/p1rZPKQuSYwTMRdOmKv9wbKFE8ieiaNHHzZV+WjWB7R3tWJqAMnkZYRSjZfgxmaF2M4K+PC3QL3IFi0qDqFDe05xL+NhuH086R9tWv29nPUpH2g== DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=60e9.5fde59e6.k2012; bh=i09HoYAthITji9s8YuJcDUzqvnReWHZujK0OXptt0t0=; b=EbiwZdwLUYDH2PNnnlXdMS+XRudQWpi24YvgZ96lfHNdImBPrLyus2aisjYL6AXmG9CaiaFeHavJ4EYnHCWzyRZnYBUvpp4UfYzW1mMilsErCxsnh6WAfvNJ4sRCbgg4EMF/q2qSsR+mbdXgxQnOFX8jjSIIG6CuSI2fWEZ7J8z9h8w4wCHqyyHbipN7M4YCWTcYE7b4oa0kTFbWjZx9REfgvfI+vCaK+62b+8EHm6dSveukNYDfiX1FavQBrKtxB9RQvRPQL9WiLdbTKa0YW5zo6of0H3eKxT/PlkC2JxCYcoHZpyQDfd0QuJegtmzqSX5/vShIjKkXNV2lhR+B6w== 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; 19 Dec 2020 19:52:05 -0000 Received: by ary.qy (Postfix, from userid 501) id 70E472ADF22A; Sat, 19 Dec 2020 14:52:04 -0500 (EST) Date: 19 Dec 2020 14:52:04 -0500 Message-Id: <20201219195205.70E472ADF22A@ary.qy> From: "John Levine" To: dmarc@ietf.org Cc: vesely@tana.it In-Reply-To: <754690b7-6624-4cc6-66e1-62438b32cdd4@tana.it> Organization: Taughannock Networks X-Headerized: yes Cleverness: minimal Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] Ticket #55 - Clarify legal and privacy implications of failure reports X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Dec 2020 19:52:09 -0000 In article <754690b7-6624-4cc6-66e1-62438b32cdd4@tana.it> you write: >On Sat 19/Dec/2020 01:03:58 +0100 Seth Blank wrote: >> >> A privacy consideration should say such a thing, specifically clarify what >> may be in a report that could be categorized as PII even after intended >> redaction, but refrain from legal advice. Given how few failure reports we're seeing, perhaps we should just take out the advice and say something like you can send these as is or redacted if you want and your policies permit, but most people don't. It's kind of amusing to know the exact names and e-mail addresses of everyone at Linkedin who subscribes to the same lists I do, but I could live without it. R's, John From nobody Sat Dec 19 12:50: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 00DF93A0F3A for ; Sat, 19 Dec 2020 12:50:48 -0800 (PST) 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=[BAYES_40=-0.001, 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 wvQmgpPi277D for ; Sat, 19 Dec 2020 12:50:46 -0800 (PST) Received: from mail-qt1-x835.google.com (mail-qt1-x835.google.com [IPv6:2607:f8b0:4864:20::835]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1B7A3A0A2C for ; Sat, 19 Dec 2020 12:50:46 -0800 (PST) Received: by mail-qt1-x835.google.com with SMTP id u21so3979309qtw.11 for ; Sat, 19 Dec 2020 12:50:46 -0800 (PST) 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=sk8yusJmGPqD0+Iioo/BS3w5hmwkZM5lq676mchLvQ0=; b=DX/cuAfnrsIL8YlKf7pYuHFK2bvARGDPpeO74f5zBuEH3ZzpeiTNEY3D6JkixUADRt Em6kgE3sUnlWcPTZ70MJNlpumpNsKoVmiDhRhM+VP+adkJ9bgj9iRMIilqK+XJJTbCEw ohVwLskTt3gbz88Vf6bt39W2fh08XA+vYK2+g4l6Ih0RXJ1q9j+xQXIbaBbV1bT1Q+Pc k/Sdr3MtHZ8AHG3Wpsy0p4KS6XrTkjBlc0zuJiC5N2RcxepNp4kxchHKNYuxX1x/FNfW xl0wwWW61dt1DQU2ynCsNFiMopxyqAJ1SPUmIwtlEcjdyBx8CRz7fXIgkiR2UAUJcnFY Mukw== 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=sk8yusJmGPqD0+Iioo/BS3w5hmwkZM5lq676mchLvQ0=; b=ZZr0PWuuBPVyEx2zmHlwlDcyB6MlI/aRFGPKFOhugzddK3AK/FQp5ZZLITRa3pQufv UVvXd0G/GwyVnDwUENE4zpDIPHn8Aa56SZi5AHZfGwNfCo8yxX60g9Rb+kSCl7vTOZD+ p/qXaI7FWyJPSnd2xnzLPB0OthnwhyR3hgql4do/E2IK0lcsk0XqucW6INk+sXGloVyW 7tXHqUi0S/EGKP0+y/X3EOwZxCI5/zmEOYIMFgs8lvCSX3G+zaowb2ijtS633P7qLODU 4k/sPSMwSwI3IVfqz3f6Apm/0J16soXOw90lZedbNvVCCKhnrSzqkfegceUIoVoNvNL9 O/Fw== X-Gm-Message-State: AOAM531mzNioJNLpRsiqQc7ivqbd/2/29d7pOFXavMJv4S2FT0RTZSXp sshbtUCJRN5AsCl3y+20xVJVN2zl9E7JYmZjFu1va+JO X-Google-Smtp-Source: ABdhPJwXjIMzBbde826X/vcnzjrv/AgOzL+N2QZVGV4QT3a1IbF6zF9KbiSYuUZmPFRDcRFOTYax7x+lGEpBUEvndRU= X-Received: by 2002:ac8:6bc2:: with SMTP id b2mr10840961qtt.286.1608411045608; Sat, 19 Dec 2020 12:50:45 -0800 (PST) MIME-Version: 1.0 References: <1e61f7c4-c6d2-5dab-dfc7-f1fd740e1d0d@tana.it> <20201219194954.BF87E2ADF1FB@ary.qy> In-Reply-To: <20201219194954.BF87E2ADF1FB@ary.qy> From: Dotzero Date: Sat, 19 Dec 2020 15:50:34 -0500 Message-ID: To: John Levine Cc: IETF DMARC WG , Alessandro Vesely Content-Type: multipart/alternative; boundary="00000000000006bf7405b6d761c7" Archived-At: Subject: Re: [dmarc-ietf] ARC vs p=quarantine X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 19 Dec 2020 20:50:48 -0000 --00000000000006bf7405b6d761c7 Content-Type: text/plain; charset="UTF-8" On Sat, Dec 19, 2020 at 2:50 PM John Levine wrote: > In article <1e61f7c4-c6d2-5dab-dfc7-f1fd740e1d0d@tana.it> you write: > >Now my tiny MX stores 115,225 domains total. And I have no idea how I > could > >add a trust-ARC-seals boolean field to each domain record. > > You wouldn't. Only a small fraction of those domains send enough forwarded > mail to be worth worrying about. We know we need some sort of shared list > of plausible forwarders but I would be amazed if it were anything like 115K > domains. > > R's, > John > So the need for a shared list has been expressed a number of times. The real question is who steps up to provide such shared lists. Michael Hammer --00000000000006bf7405b6d761c7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Sat, Dec 19, 2020 at 2:50 PM John = Levine <johnl@taugh.com> wrote= :
In article <= ;1e61f7c4-c6d2-5dab-dfc7-f1fd740e1d0d@tana.it> you write:
>Now my tiny MX stores 115,225 domains total.=C2=A0 And I have no idea h= ow I could
>add a trust-ARC-seals boolean field to each domain record.

You wouldn't.=C2=A0 Only a small fraction of those domains send enough = forwarded
mail to be worth worrying about.=C2=A0 We know we need some sort of shared = list
of plausible forwarders but I would be amazed if it were anything like 115K=
domains.

R's,
John

So the need for a shared list has = been expressed a number of times. The real question is who steps up to prov= ide such shared lists.

Michael Hammer
--00000000000006bf7405b6d761c7-- From nobody Sun Dec 20 03:00:13 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 132123A0EF4 for ; Sun, 20 Dec 2020 03:00:09 -0800 (PST) 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 8ifK5x-9DTa1 for ; Sun, 20 Dec 2020 03:00:07 -0800 (PST) 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 707713A0EF2 for ; Sun, 20 Dec 2020 03:00:06 -0800 (PST) Received: (qmail 50483 invoked by uid 100); 20 Dec 2020 11:00:06 -0000 Date: 20 Dec 2020 10:59:42 -0000 Message-ID: <20201220105942.50471.qmail@submit.iecc.com> From: "John Levine" To: dmarc@ietf.org Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Archived-At: Subject: [dmarc-ietf] Messages from the dmarc list for the week ending Sun Dec 20 06:00:05 2020 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Dec 2020 11:00:09 -0000 Count | Bytes | Who ------------+----------------+------- 10 (23.3%) | 61316 (13.9%) | Alessandro Vesely 6 (14.0%) | 29727 ( 6.7%) | John Levine 5 (11.6%) | 95589 (21.7%) | Douglas Foster 5 (11.6%) | 34737 ( 7.9%) | Michael Thomas 3 ( 7.0%) | 82453 (18.7%) | Laura Atkins 3 ( 7.0%) | 29435 ( 6.7%) | Dotzero 3 ( 7.0%) | 10855 ( 2.5%) | Dave Crocker 2 ( 4.7%) | 33759 ( 7.7%) | Todd Herr 2 ( 4.7%) | 24000 ( 5.4%) | Brotman, Alex 1 ( 2.3%) | 13894 ( 3.1%) | Seth Blank 1 ( 2.3%) | 10897 ( 2.5%) | Henning Krause 1 ( 2.3%) | 8148 ( 1.8%) | Tim Wicinski 1 ( 2.3%) | 6362 ( 1.4%) | Dave Crocker From nobody Sun Dec 20 03:44:12 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EDFD3A0F13 for ; Sun, 20 Dec 2020 03:44:10 -0800 (PST) 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, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 04Au3GQUstfK for ; Sun, 20 Dec 2020 03:44:08 -0800 (PST) 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 703AC3A0F0F for ; Sun, 20 Dec 2020 03:44:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1608464643; bh=RFwOnRjw4WTTdYP2CugF4hd+icwnpKSyL+VNHoozPgw=; l=793; h=To:References:From:Date:In-Reply-To; b=CpxVm9o8UmXPQZ4l6URpj3jAwnz62DeoaRezkTxbp/BNNwb/b0CJJr9NIpAxcgWRt kVAM06cfo9bkxmHy4pxdFvFgJcjYG0VDw47362L1D/KUBKmLyvh+Kmbyq+YBCFnSgT k/f2+a1SeD3qOWKWx2t6i9qAg92FuGA5nuDK82G4XwzqyoTjKTibxw2Qpy0Zj Authentication-Results: tana.it; auth=pass (details omitted) Original-From: Alessandro Vesely 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.000000005FDF3903.00007409; Sun, 20 Dec 2020 12:44:03 +0100 To: Dotzero , John Levine , IETF DMARC WG References: <1e61f7c4-c6d2-5dab-dfc7-f1fd740e1d0d@tana.it> <20201219194954.BF87E2ADF1FB@ary.qy> From: Alessandro Vesely Message-ID: <9b7cc1c9-e031-4ef8-8d92-2c16cc4fa073@tana.it> Date: Sun, 20 Dec 2020 12:44:03 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] ARC vs p=quarantine X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 20 Dec 2020 11:44:10 -0000 On Sat 19/Dec/2020 21:50:34 +0100 Dotzero wrote: > On Sat, Dec 19, 2020 at 2:50 PM John Levine wrote: >> In article <1e61f7c4-c6d2-5dab-dfc7-f1fd740e1d0d@tana.it> you write: >>> Now my tiny MX stores 115,225 domains total. And I have no idea how I >>> could add a trust-ARC-seals boolean field to each domain record. >> >> You wouldn't. Only a small fraction of those domains send enough >> forwarded mail to be worth worrying about. We know we need some sort of >> shared list of plausible forwarders but I would be amazed if it were >> anything like 115K domains. > > So the need for a shared list has been expressed a number of times. The real > question is who steps up to provide such shared lists. Dnswl.org counts about 25K domains. Best Ale -- From nobody Sun Dec 20 03: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 950383A0F2F for ; Sun, 20 Dec 2020 03:48:00 -0800 (PST) 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, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 Cr-2n79pzKle for ; Sun, 20 Dec 2020 03:47:59 -0800 (PST) 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 332D23A0F2E for ; Sun, 20 Dec 2020 03:47:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1608464876; bh=tjW2tR115gezbxfymX53f2xFpO8GOGeYStzlCayaoFc=; l=719; h=To:References:From:Date:In-Reply-To; b=DC80kNaDA0UeE/5dBiLyWR+jqa6/9uO9GiqRYGSVgqVgrufbz6w3bxfdVVaWY6690 iT3DDupLyF6w/q7ftawbJawCWrqRUCq2ZOGYs6rSMhASfiAjOvafP/lHsPcu7VTs7f 2JVsafIWQvuFdFmJr6kfu3eqdbSntWCR5mmKOKryS+Kn58dCNzaAulnI2aKIy Authentication-Results: tana.it; auth=pass (details omitted) Original-From: Alessandro Vesely 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.000000005FDF39EC.00007479; Sun, 20 Dec 2020 12:47:56 +0100 To: John R Levine , dmarc@ietf.org References: <20201218023900.E73B82ACBB2B@ary.qy> <4a43ffaa-3987-c892-cce7-56f18888cdf5@tana.it> <39125012-e356-d62d-36fd-a7ff25a9f59f@taugh.com> From: Alessandro Vesely Message-ID: Date: Sun, 20 Dec 2020 12:47:56 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: <39125012-e356-d62d-36fd-a7ff25a9f59f@taugh.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] Ticket #55 - Clarify legal and privacy implications of failure reports X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Dec 2020 11:48:01 -0000 On Fri 18/Dec/2020 21:05:43 +0100 John R Levine wrote: >> Info which is encoded in such a way that only the sender can understand rises >> no PII concern, IMHO.  A sender could cache sent messages and devise how to >> encode the corresponding filenames in DKIM selectors.  Reporting just the >> failed signature would leak the whole message by reference.  So what? > > Now he knows which forwarded recipients are talking with his users. Are failure reports about forwarded messages still useful? If not so much, perhaps we could deplore them. Keeping the target of forwarded messages private needs to be addressed at emailcore as well, though. Regular bounces leak the same info. Best Ale -- From nobody Sun Dec 20 09:10: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 A65B93A10A9 for ; Sun, 20 Dec 2020 09:10:23 -0800 (PST) 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 3_i6tpwd5-wC for ; Sun, 20 Dec 2020 09:10:21 -0800 (PST) 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 223723A0B60 for ; Sun, 20 Dec 2020 09:10:20 -0800 (PST) Received: by mail-qk1-x729.google.com with SMTP id h4so6964516qkk.4 for ; Sun, 20 Dec 2020 09:10:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=gJwmOhOaImMtP2uJrSEdAL1REBUifSxHA+rhBiFXI8M=; b=HVg69XAdeXy7MFc5Km19Lgr1ticmXuuSCG1I2NrQJAPw1bPIWbpxdh2U4dSJu3v6+E r5Hcm5P8YusMlsBj2briESZMJesHc3AenII/Thrlc7TdjiDUkqPDZxCSb+9kujuYTdVj sb1bsFsiKiEI+3N0DBfC5cEez0/OWK1dFudeWtpWFDhQgxtkAn9NKG+2b1Z+oE17eYdM PKeHA8BN6h/tFT+qqs+lROak5VjPdf94u+DU3SnIx4nqui4tjlsrJ6/NTfgeCxP13Uko 2J2KvqxkiDbw1huQJIvpZepRFysztklv6rxXOdH4QnQXnysj8adCQ7FaeJ+5ZeOLNnie sp7g== 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=gJwmOhOaImMtP2uJrSEdAL1REBUifSxHA+rhBiFXI8M=; b=fphFZgxeN1K4JS1m1GFqQd0Vm3Df4oBTwUuI19IgRp6M1cq9m3INHKjR9w4suA5Gfq ZRdFpAJfulh3H7i8I1+T221q1sl1fo7WVZc0owxq8sOt69t57XNu1Q5zj/1c5RHaFYF3 IebBlUox1pBi5m4uG8cq/G9Ffm2xW1OmVnXAluehXp/h3UXoNkHdnInh3LYCHv03znkE 9iE28YQ5Mdt4wLddeqlh8akpHaLGxA8ChMmB/V+/BnhuXruTZrn70y9cLHe+wxUQ8Hlk txrOEFrsTFGA+L0sTDumNGp+Egts//waEpFUznLqUAXvbRo41FdWspT8uHaddgQSGDmN tZBQ== X-Gm-Message-State: AOAM533Gh+A+yET0dFkF+1Gub+Fvi0B6gLpwKEjIcuZowZCo+gbbULcM RkbuLXbOGlOXJ9AgL8cX6784OwV6fM7qwYMq9troPHOUUMr70A== X-Google-Smtp-Source: ABdhPJx80/udodXA3p5GNxG+eBQmuWqVw6kjAQS01bGeU6bIWwOWNldZO7lSTSogJPN2KnmQH1Buwrxwrmqffkr4IL8= X-Received: by 2002:a37:e20d:: with SMTP id g13mr14249482qki.325.1608484219437; Sun, 20 Dec 2020 09:10:19 -0800 (PST) MIME-Version: 1.0 References: <20201211173722.6B4DF29782C7@ary.qy> <02f786e5-b7cd-9a89-e3e3-73594f3bcda0@mtcc.com> In-Reply-To: From: Todd Herr Date: Sun, 20 Dec 2020 12:10:03 -0500 Message-ID: To: IETF DMARC WG Content-Type: multipart/alternative; boundary="00000000000086d42805b6e86acd" Archived-At: Subject: Re: [dmarc-ietf] p=quarantine X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 20 Dec 2020 17:10:24 -0000 --00000000000086d42805b6e86acd Content-Type: text/plain; charset="UTF-8" On Fri, Dec 18, 2020 at 4:55 PM Michael Thomas wrote: > > On 12/15/20 8:01 AM, Todd Herr wrote: > > > I'm not sure there's anything actionable about DMARC's policy values. > > you mean p=quarantine, or p=* in general? > Depending on the level of sophistication of a receiving email system, a given email message can have dozens of signals (or data points) associated with it, of which the relevant DMARC policy record, if it exists, is one. Those signals can all be actionable, individually or collectively, or ignored entirely, in that receiving system's decision to accept or reject the message, and if it accepts it, the decision of where to place that message. If an applicable DMARC policy record exists for the RFC5322.From domain in a message, the receiver can: - Perform the necessary authentication checks for DMARC validation, and use those validation results and the p= value as the sole or primary determining factor in how to handle the message, strictly applying the p= value in cases where it's not 'none' and validation checks fail - Perform the necessary authentication checks for DMARC validation, and use those validation results and the p= value as the sole or primary determining factor in how to handle the message, loosely applying the p= value in cases where it's not 'none' and validation checks fail (e.g., placing the message in the spam folder even if p=reject is specified in the policy record) - Perform the necessary authentication checks for DMARC validation, and use those validation results and the p= value as one data point in a larger data set in how to handle the message - Ignore the DMARC policy record entirely > Obviously indirect mail flows, such as mailing lists and forwarding, > complicate matters greatly here, as the handling by the intermediary > host(s) can and will lead to a higher percentage of authentication > failures. The community has attempted to mitigate this problem; > RFC5322.From header rewriting, RFC5321.From header rewriting (e.g., SRS), > and ARC are among the attempts put forth so far, but none have been deemed > The Solution(tm) yet. In my opinion, ARC has promise, because if a message > reaches me as a receiver or even intermediary and fails the authentication > checks I perform, ARC header sets in the message can tell me whether or not > such checks passed at previous hops *if I trust the entities that inserted > those ARC header sets*. In an earlier thread, I floated an idea about ARC > sealer reputation, but it didn't draw much response, so I'll float it here > again in the hopes that it does. > > We've always been able to check the reputation of lists that resign the > message. The reputation is the previously (un)solved problem. > > > Lists are a specific instance of the more general case of indirect mail flows. Any intermediate host can ARC seal and ARC-sign (a term I use as distinct from re-sign) a message, an act that is meant to capture the results of authentication checks done when it reached the intermediary. Whether or not the receiver trusts those results (especially those results that claim that authentication checks passed at the intermediary) when the message reaches the receiver depends on the intermediary's reputation for being a truthful sealer and signer, meaning whether or not it has established a history of capturing authentication results that are true and accurate. Since the receiver typically can't perform the same checks under the same conditions that existed when the intermediary performed them (if it could, we wouldn't need something like ARC) then the receiver has to decide if the message is consistent with messages it's previously seen through direct mail flows using that same authenticated identity that was captured by the intermediary in the ARC header set. If the indirect mail flow looks like the direct mail flow, then the sealer is showing evidence that it can be trusted, and so the indirect mail flow can receive the same treatment by the receiver that it would give to the direct mail flow associated with the authenticated identity. If the indirect mail flow looks different than the direct mail flow, then the receiver can either decide to not trust the sealer and so treat the indirect mail flow as unauthenticated, or perhaps it can dig into matters further to see why the difference exists. A mailing list, for example, that has subscribers whose domain is a consumer mailbox provider might just show an indirect mail flow for that domain to the receiver that has a substantially better overall reputation than the direct mail flow for that domain to the receiver; rather than letting this difference impact the level of trust in its sealing reputation that a receiver would assign to the list, it may very well have to put in an override to its system for tracking sealer trust. -- *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. --00000000000086d42805b6e86acd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Fri, Dec 18, 2020 at 4:55 PM Michael T= homas <mike@mtcc.com> wrote:
=
=20 =20 =20


On 12/15/20 8:01 AM, Todd Herr wrote:
=20

I'm not sure there's anything actionable about DMARC= 's policy values.

you mean p=3Dquarantine, or p=3D* in general?


Depending on the level of sophistication of a recei= ving email system, a given email message can have dozens of signals (or dat= a points) associated with it, of which the relevant DMARC policy record, if= it exists, is one. Those signals can all be actionable, individually or co= llectively, or ignored entirely, in that receiving system's decision to= accept or reject the message, and if it accepts it, the decision of where = to place that message.

If an applicable DMARC poli= cy record exists for the RFC5322.From domain in a message, the receiver can= :
  • Perform the necessary authentication checks for DMARC v= alidation, and use those validation results and the p=3D value as the sole = or primary determining factor in how to handle the message, strictly applyi= ng the p=3D value in cases where it's not 'none' and validation= checks fail
  • Perform the necessary authentication checks for DMARC = validation, and use those validation results and the p=3D value as the sole= or primary determining factor in how to handle the message, loosely applyi= ng the p=3D value in cases where it's not 'none' and validation= checks fail (e.g., placing the message in the spam folder even if p=3Dreje= ct is specified in the policy record)
  • Perform the necessary aut= hentication checks for DMARC validation, and use those validation results a= nd the p=3D value as one data point in a larger data set in how to handle t= he message
  • Ignore the DMARC policy record entirely


Obviously indirect mail flows, such as mailing lists and forwarding, complicate matters greatly here, as the handling by the intermediary host(s) can and will lead to a higher percentage of authentication failures. The community has attempted to mitigate this problem; RFC5322.From header rewriting, RFC5321.From header rewriting (e.g., SRS), and ARC are among the attempts put forth so far, but none have been deemed The Solution(tm) yet. In my opinion, ARC has promise, because if a message reaches me as a receiver or even intermediary and fails the authentication checks I perform, ARC header sets in the message can tell me whether or not such checks passed at previous hops *if I trust the entities that inserted those ARC header sets*. In an earlier thread, I floated an idea about ARC sealer reputation, but it didn't draw much response, so I'll float it here aga= in in the hopes that it does.

We've always been able to check the reputation of lists that resign the message. The reputation is the previously (un)solved problem.


Lists are a specific instance of the= more general case of indirect mail flows.=C2=A0

A= ny intermediate host can ARC seal and ARC-sign (a term I use as distinct fr= om re-sign) a message, an act that is meant to capture the results of authe= ntication checks done when it reached the intermediary. Whether or not the = receiver trusts those results (especially those results that claim that aut= hentication checks passed at the intermediary) when the message reaches the= receiver depends on the intermediary's reputation for being a truthful= sealer and signer, meaning whether or not it has established a history of = capturing authentication results that are true and accurate.=C2=A0

Since the receiver typically can't perform the same ch= ecks under the same conditions that existed when the intermediary performed= them (if it could, we wouldn't need something like ARC) then the recei= ver has to decide if the message is consistent with messages it's previ= ously seen through direct mail flows using that same authenticated identity= that was captured by the intermediary in the ARC header set.=C2=A0

If the indirect mail flow looks like the direct mail flow= , then the sealer is showing evidence that it can be trusted, and so the in= direct mail flow can receive the same treatment by the receiver that it wou= ld give to the direct mail flow associated with the authenticated identity.= =C2=A0

If the indirect mail flow looks different t= han the direct mail flow, then the receiver can either decide to not trust = the sealer and so treat the indirect mail flow as unauthenticated, or perha= ps it can dig into matters further to see why the difference exists. A mail= ing list, for example, that has subscribers whose domain is a consumer mail= box provider might just show an indirect mail flow for that domain to the r= eceiver that has a substantially better overall reputation than the direct = mail flow for that domain to the receiver; rather than letting this differe= nce impact the level of trust in its sealing reputation that a receiver wou= ld assign to the list, it may very well have to put in an override to its s= ystem for tracking sealer trust.

--=C2=A0

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 recip= ient you are hereby notified of any use, disclosure, copying or distributio= n of the information included in this transmission is prohibited and may be= unlawful. Please immediately notify the sender by replying to this email a= nd then delete it from your system.

--00000000000086d42805b6e86acd-- From nobody Sun Dec 20 10:14: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 611B93A112D for ; Sun, 20 Dec 2020 10:13:58 -0800 (PST) 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 (2048-bit key) header.d=iecc.com header.b=vR8tLVMR; dkim=pass (2048-bit key) header.d=taugh.com header.b=GTjMmgZq Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id McHVKdxiuYIl for ; Sun, 20 Dec 2020 10:13:56 -0800 (PST) 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 9498D3A0F74 for ; Sun, 20 Dec 2020 10:13:56 -0800 (PST) Received: (qmail 54253 invoked from network); 20 Dec 2020 18:13:51 -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=d3eb.5fdf945f.k2012; i=johnl-iecc.com@submit.iecc.com; bh=7TP9LEJ4s8Pm8iVQFVRHEgnZTu9A8aD0mkiPo+T49Oo=; b=vR8tLVMRlcgV1X3sf+xlULupWGaZfWl5qKbBW2LWC9YUMy84XRVORUxdiEx+EdkaUF6qZ9gePv8Sehp1r3rgYElyIP2sphwzAIHy9lC/k17p5kj/DI4SYOxv0TkTIvRdhiLAcM9Shre07jxmn5C0coiTI8Upw1pSt8wVmMvVlF+Bn+0q94OWgRqVuEaeUQ0CXg0ruKGwy6qg6G6Tcm18h81JTOW8rJitS2EN+8xPZmSn7K93YFF7e1UkRt9bvVWgGnzltUeEw34Fc6LnPwBOWe5h2f/CF6eiNqUNbCOqw+tA0VIa9vcRiqIkSusPHA5nIfLn2F4HAJL4YUBM/gS/qQ== 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=d3eb.5fdf945f.k2012; olt=johnl-iecc.com@submit.iecc.com; bh=7TP9LEJ4s8Pm8iVQFVRHEgnZTu9A8aD0mkiPo+T49Oo=; b=GTjMmgZqubEzCfY9jGSXoNnSFX4U09eLz/E+oS5VOERR/Hdf6j+vfg3wmc3PO+qmec/cqqXv0Kk6O5cLmqhwRQIE5kXb3bFAzdVdJMg31pNBCnM5H677DJatnpopm4HlPAxF+w37UY61FgRfifRE8XzhM7ycHRFnyjlhkPvFloQoBtYSydqZLS45PahWIHbPRz9aKT86XoN1FaanJCSFUP/1r09Be/W4cBHBuxo2ZOaKPNgWpmfyi27aQnMG5BSfNwtr/y77Yep+bK75tY7xTxExRYmIIJyVxidR+tLvNL7AwetPIc0T7q1hufkTlD972Gyz6Ru8rBnLYwu0RN3AUQ== 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; 20 Dec 2020 18:13:51 -0000 Date: 20 Dec 2020 13:13:51 -0500 Message-ID: From: "John R Levine" To: "Alessandro Vesely" , "IETF DMARC WG" In-Reply-To: <9b7cc1c9-e031-4ef8-8d92-2c16cc4fa073@tana.it> References: <1e61f7c4-c6d2-5dab-dfc7-f1fd740e1d0d@tana.it> <20201219194954.BF87E2ADF1FB@ary.qy> <9b7cc1c9-e031-4ef8-8d92-2c16cc4fa073@tana.it> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [dmarc-ietf] ARC vs p=quarantine X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 20 Dec 2020 18:13:58 -0000 On Sun, 20 Dec 2020, Alessandro Vesely wrote: >> question is who steps up to provide such shared lists. > > Dnswl.org counts about 25K domains. I suppose one might try them but I expect most of them are not sending forwarded mail. I've finally gotten around to doing ARC checks in my SMTP daemon so I can see who's adding ARC seals. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From nobody Sun Dec 20 10:17: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 371DB3A1135 for ; Sun, 20 Dec 2020 10:17:07 -0800 (PST) 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 (2048-bit key) header.d=iecc.com header.b=E8Y3HQz3; dkim=pass (2048-bit key) header.d=taugh.com header.b=Tibgi/Y7 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jPotDNrDxdPp for ; Sun, 20 Dec 2020 10:17:05 -0800 (PST) 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 75C4F3A1133 for ; Sun, 20 Dec 2020 10:17:05 -0800 (PST) Received: (qmail 55083 invoked from network); 20 Dec 2020 18:17: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=d729.5fdf9520.k2012; i=johnl-iecc.com@submit.iecc.com; bh=VBL3Me2W20nHaYrBtBY9EOLn+bsixR0/M3gTsRB89Zg=; b=E8Y3HQz36zwCAYH8IeytDIKeM17ELF7s9gTLKduI5qlMXU1yn/ebWwZDVjP61+JYqmZEUEDfBuYNJ4Z3ElZ7fHJq08j6ZaRoeZI8H+M7RIdnYYgf5zOXRSm67CfxnXtyKzd3YxmW5qmu6ArJv217AUIeqB0CIdP3mZGI98JUHX07IlbhD+opbcrLQNo9GYE5m1Hp611irLiEF6Jb05E5eqOyzgErqhFOlcoqGIRvM8cqJ5pYX7dlRkkffWt9ZoafgFgi+T+vMTHfPVzO4Kwd0UrAJV8ti46wk+JeoRdFeRyFc5F7y33ZS/MuQZ2OPsGsc4E87h17TNu/WRCTTKfOxQ== 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=d729.5fdf9520.k2012; olt=johnl-iecc.com@submit.iecc.com; bh=VBL3Me2W20nHaYrBtBY9EOLn+bsixR0/M3gTsRB89Zg=; b=Tibgi/Y7wOMTWA6hu9ve8s2MJaAsCGSYoPiIySBkFpXXi+QcC0MrFIo7OO00ZaZGQyKvbfKBjUaq24Cb9cWp28FjqXrCF68wx1az20BV5CYSK6bhu5irujE0Nt0MXWUWQbk+aOG/HpgM20PAkKLVr3zo8bGm/JlPKMa0q6e3Yqg9ARoG02jcJzTdOzj6J90nN5t4lDyGsH8/cvkzwZnrTu/N5q4O9Xm/cuBteskqILgDlnBYDRRnrGnxiRN6oXPIF+a6NzdpMvYa7+CXOxFIc9Xgp1eMp3JcFepx7Q7FgqSXoW0Wqzn6wHWCmTrdRmmYPOLKPE5A+B16GV9ygwwK5g== 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; 20 Dec 2020 18:17:04 -0000 Date: 20 Dec 2020 13:17:03 -0500 Message-ID: <6bba023-d3d9-63a5-8441-11dac9a05e28@taugh.com> From: "John R Levine" To: "Alessandro Vesely" , dmarc@ietf.org In-Reply-To: References: <20201218023900.E73B82ACBB2B@ary.qy> <4a43ffaa-3987-c892-cce7-56f18888cdf5@tana.it> <39125012-e356-d62d-36fd-a7ff25a9f59f@taugh.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [dmarc-ietf] Ticket #55 - Clarify legal and privacy implications of failure reports X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Dec 2020 18:17:07 -0000 > On Fri 18/Dec/2020 21:05:43 +0100 John R Levine wrote: >> [ failure reports leak PII including forwarded recipients ] > Are failure reports about forwarded messages still useful? If not so much, > perhaps we could deplore them. There's no mechanical way to tell whether a message has been forwarded as opposed to bcc or a mailing list or a local redistribution list or whatever. Given how few sites send failure messages, and that we all seem able to manage our DMARC setups without them, I don't think they're worth a lot of effort. Hence my suggestion for simplified advice. > Keeping the target of forwarded messages private needs to be addressed at > emailcore as well, though. Regular bounces leak the same info. That seems like a great way to destroy mailing lists by not telling them which recipients are bouncing. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From nobody Sun Dec 20 12:53: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 6BED53A11BC for ; Sun, 20 Dec 2020 12:53:34 -0800 (PST) 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 d0D8yO9XSmUk for ; Sun, 20 Dec 2020 12:53:31 -0800 (PST) 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 0C11D3A11B9 for ; Sun, 20 Dec 2020 12:53:30 -0800 (PST) Received: by mail-vs1-xe2b.google.com with SMTP id e15so4351888vsa.0 for ; Sun, 20 Dec 2020 12:53:30 -0800 (PST) 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=TbfxXOExc0uZoRN0a+15B5sP5/y23sirqL9ZE+H0CFk=; b=D0QS9furp6GmGNyk2cutcs2AnGIsjoWNlftabYpI/6m2B1Ed7fOucFzt4tcKGkpRr7 D9cveOsLs+m7Z5quubOLLVgNGWRqWX2EEXeUHKT3o+Swnv7CEQYogo4MehuUB/mUYEkw E4r24F3hQzCNtyUi2S1Wb0DHt87dLjj3jWTh9QysrnzAAQ2bbZYMU6tbHM1azPU7dqBo lbc5+OfbhrNIDprt5qjMtpMO9HLN5bLCRrLxOaaJ5zJBHBUfea3H0J/EfVQZNkeDX17m CtItBbtfF1xbo4wt7qy0cLXVxlM1B+1n3GIXpWSy8R4qFav2He6J7IaJtAtYtUKPHMBL 9Crg== 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=TbfxXOExc0uZoRN0a+15B5sP5/y23sirqL9ZE+H0CFk=; b=DAnwzOx8kcc7IQnx1rOr+HBIAndxyuuDLrIzl9gHK3eyUx8dbLKrFQBTvIdR/685Q+ frPOlw1UiDPLEdXojqU5fm4ZEBmRoN0qZVfFs3uYvhrV4iD3o5BwjCi9BlWALcfSv0cJ +J9dr8QE4XuVUPlQmCgd7TVWGFsrPJ9nmhQKeYx2dzvpeSdeR8Zz2o8A54QQaIvioItM 5Ub0gvMa2NSebhnAG9JXlCCFn/dns4+1OVKusWO3y1Toc1MiEPzOCwDw3oSrlX8p19xy o3dgXLQnEd2Qg4w/vhQO44H6YfHtnbR+waVqaFJZIXsH8JUfuplekgLTp6iwVcbvmltL qx+A== X-Gm-Message-State: AOAM531sJW7pN4mc+gwBAiXfRLLPmJbnMsiPqAcXFpFh3DYvc8iNeA1p wvfxiTY0R2ZLO/2gb75nklliPreAVCJvVDNtQCo= X-Google-Smtp-Source: ABdhPJxk+4K5PjCDmEn9oK24rj3iE4wHuKXWL+vUjA1mlBlmGSFkgMOQFxRyFH94BoupBkCQySyeG/9eTdVFroB1jhM= X-Received: by 2002:a67:c983:: with SMTP id y3mr10810162vsk.59.1608497609924; Sun, 20 Dec 2020 12:53:29 -0800 (PST) MIME-Version: 1.0 References: <20201211173722.6B4DF29782C7@ary.qy> <02f786e5-b7cd-9a89-e3e3-73594f3bcda0@mtcc.com> In-Reply-To: From: Douglas Foster Date: Sun, 20 Dec 2020 15:53:19 -0500 Message-ID: To: Todd Herr Cc: IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000a964fd05b6eb8874" Archived-At: Subject: Re: [dmarc-ietf] p=quarantine X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 20 Dec 2020 20:53:34 -0000 --000000000000a964fd05b6eb8874 Content-Type: text/plain; charset="UTF-8" Like any security problem, we need to minimize false positives (desired mail being blocked) and false negatives (unwanted or malicious mail being allowed). ARC will hopefully address the false positives, but the false negative issue remains. The situation does not seem hopeless, but the topic does appear to be underdeveloped. Here are some observations: SPF PASS means the message was received directly from the stated domain, but it does not indicate whether or not the stated domain was the originator, since the SMTP address may have been rewritten. Similarly, SPF FAIL indicates that the message was not received directly from the stated domain, but it cannot distinguish between a message that originated from an unauthorized source and a message that originated from an authorized source but was then forwarded without SMTP rewrite. The FAIL could also be the result of a DNS configuration error, such as a domain that changed hosting services without changing their SPF policy record. The issues with failed DKIM signatures and From rewrite are similar. A forwarded message may have: - no address rewrite causing SPF FAIL but no masking of the originator address, - transparent address rewrite using SRS or ARC, or - non-transparent replacement of prior SMTP and/or From addresses, without SRS or ARC clues being included (as this list). Consequently, the only reliable way to detect an untrusted source behind a forwarder is to evaluate the entire message header chain. Blacklisting --------------- For purposes of filtering unwanted messages, verifiable header data is not required. (If someone wants to spoof an untrusted sender, I am happy to consider that spoofer untrusted also.) The Received chain can be checked for IP addresses and DNS names with negative reputation. Similarly, any Received-SPF, Authentication-Results, ARC-Authenticated-Results, Authenticated-As or similar headers can be checked for email domain names with negative reputation. All of this can and should be done regardless of the SPF and DMARC status, because SPF and DMARC are designed around direct mail flows, and SPF and DMARC pass can be achieved by pretending to be a direct mail flow. An additional test is to count the number of organizations that handled the message along the delivery path. First, consolidate out the Received headers with private IPs or loopback IPs, then (probably) drop any messages transferred over LMTP, and any transfers where the ReverseDNS and HELO domains are unchanged in the handoff. What should be left is a small number of entries where the FROM information indicates the IP and hostnames of the sending organization and the HELO name should be an MX of the receiving organization. (SPF checks and Forward-confirmed DNS checks can then be performed on this data.) For direct messages, I assume that the maximum number of organization boundaries should be three: - Cloud-based SMTP submitting client to mailstore organization, - mailstore organization to cloud-based outbound filtering service, - then outbound filtering service to destination domain. Additionally, the cloud-based outbound filtering services are relatively few and well known, which should simplify determining whether an intermediate organization is a filtering service or a forwarding service. It seems axiomatic that a forwarder will have an unreliable reputation with recipients. If the forwarder blocks a message, the recipient system will not directly know that it was blocked, whether the blocked message was wanted or unwanted. But if the forwarder allows a message that the recipient does not want, the forwarder takes a hit on its reputation. An automated forwarding service has an incentive to avoid false positives, so it is almost certain to have a spam filtering policy which is weaker than the final recipient system. Rather than blaming the forwarding service for unwanted messages getting through, the evaluator should look at the entire received chain. Whitelisting --------------- It is much riskier to perform whitelisting based on the header data, because one must allow for the possibility that a nation-state attacker will construct a convincing but fraudulent header chain, if they perceive that doing so will succeed. But I cannot imagine whitelisting a message from a random forwarder based on header data alone. I would only do that if the forwarding service, message originator, and forwarding path were well understood from external sources. In that case, a message from a well-identified forwarding service with a sufficiently-identified message originator might be a candidate for whitelisting. But those situations seem likely to be rare. Conclusion --------------- The overall conclusion is that if a message's only negative indicator is an authentication failure, the best practice would be to send it to administrative quarantine for local policies to be tailored to the situation. It seems foolish to block a message if sender authentication failure is the only problem, unless domain abuse is actually confirmed during the quarantine review. It seems even more foolish to filter only on the identities provided by the submitting node, without evaluating the entire header structure. The unfortunate part of all this is that I suspect very few commercial products evaluate the entire header. Does anyone have data on this question? Where full scans are not implemented now, switching to a full scan will significantly increase the processing overhead per message, which will impact throughput. Doug Foster On Sun, Dec 20, 2020 at 12:10 PM Todd Herr wrote: > On Fri, Dec 18, 2020 at 4:55 PM Michael Thomas wrote: > >> >> On 12/15/20 8:01 AM, Todd Herr wrote: >> >> >> I'm not sure there's anything actionable about DMARC's policy values. >> >> you mean p=quarantine, or p=* in general? >> > > Depending on the level of sophistication of a receiving email system, a > given email message can have dozens of signals (or data points) associated > with it, of which the relevant DMARC policy record, if it exists, is one. > Those signals can all be actionable, individually or collectively, or > ignored entirely, in that receiving system's decision to accept or reject > the message, and if it accepts it, the decision of where to place that > message. > > If an applicable DMARC policy record exists for the RFC5322.From domain in > a message, the receiver can: > > - Perform the necessary authentication checks for DMARC validation, > and use those validation results and the p= value as the sole or primary > determining factor in how to handle the message, strictly applying the p= > value in cases where it's not 'none' and validation checks fail > - Perform the necessary authentication checks for DMARC validation, > and use those validation results and the p= value as the sole or primary > determining factor in how to handle the message, loosely applying the p= > value in cases where it's not 'none' and validation checks fail (e.g., > placing the message in the spam folder even if p=reject is specified in the > policy record) > - Perform the necessary authentication checks for DMARC validation, > and use those validation results and the p= value as one data point in a > larger data set in how to handle the message > - Ignore the DMARC policy record entirely > > > >> Obviously indirect mail flows, such as mailing lists and forwarding, >> complicate matters greatly here, as the handling by the intermediary >> host(s) can and will lead to a higher percentage of authentication >> failures. The community has attempted to mitigate this problem; >> RFC5322.From header rewriting, RFC5321.From header rewriting (e.g., SRS), >> and ARC are among the attempts put forth so far, but none have been deemed >> The Solution(tm) yet. In my opinion, ARC has promise, because if a message >> reaches me as a receiver or even intermediary and fails the authentication >> checks I perform, ARC header sets in the message can tell me whether or not >> such checks passed at previous hops *if I trust the entities that inserted >> those ARC header sets*. In an earlier thread, I floated an idea about ARC >> sealer reputation, but it didn't draw much response, so I'll float it here >> again in the hopes that it does. >> >> We've always been able to check the reputation of lists that resign the >> message. The reputation is the previously (un)solved problem. >> >> >> Lists are a specific instance of the more general case of indirect mail > flows. > > Any intermediate host can ARC seal and ARC-sign (a term I use as distinct > from re-sign) a message, an act that is meant to capture the results of > authentication checks done when it reached the intermediary. Whether or not > the receiver trusts those results (especially those results that claim that > authentication checks passed at the intermediary) when the message reaches > the receiver depends on the intermediary's reputation for being a truthful > sealer and signer, meaning whether or not it has established a history of > capturing authentication results that are true and accurate. > > Since the receiver typically can't perform the same checks under the same > conditions that existed when the intermediary performed them (if it could, > we wouldn't need something like ARC) then the receiver has to decide if the > message is consistent with messages it's previously seen through direct > mail flows using that same authenticated identity that was captured by the > intermediary in the ARC header set. > > If the indirect mail flow looks like the direct mail flow, then the sealer > is showing evidence that it can be trusted, and so the indirect mail flow > can receive the same treatment by the receiver that it would give to the > direct mail flow associated with the authenticated identity. > > If the indirect mail flow looks different than the direct mail flow, then > the receiver can either decide to not trust the sealer and so treat the > indirect mail flow as unauthenticated, or perhaps it can dig into matters > further to see why the difference exists. A mailing list, for example, that > has subscribers whose domain is a consumer mailbox provider might just show > an indirect mail flow for that domain to the receiver that has a > substantially better overall reputation than the direct mail flow for that > domain to the receiver; rather than letting this difference impact the > level of trust in its sealing reputation that a receiver would assign to > the list, it may very well have to put in an override to its system for > tracking sealer trust. > > -- > > *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. > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > --000000000000a964fd05b6eb8874 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Like any security problem, we need to minimize false posit= ives (desired mail being blocked) and false negatives (unwanted or maliciou= s mail being allowed).=C2=A0 ARC will hopefully address the false positives= , but the false negative issue remains.=C2=A0 =C2=A0The situation does not = seem hopeless, but the=C2=A0topic does appear to be underdeveloped.=C2=A0 = =C2=A0Here are some observations:

SPF PASS means the mes= sage was received directly from the stated domain, but it does not indicate= whether or not the stated domain was the originator, since the SMTP addres= s may have been rewritten.=C2=A0 =C2=A0Similarly, SPF FAIL indicates that t= he message was not received directly from the stated domain, but it cannot = distinguish between a message that originated from an unauthorized source a= nd a message that originated from an authorized source but was then forward= ed without SMTP rewrite.=C2=A0 =C2=A0 The FAIL could also be the result of = a DNS configuration error, such as a domain that changed hosting services w= ithout changing their SPF policy record.=C2=A0 =C2=A0 The issues with faile= d=C2=A0DKIM signatures and From rewrite are similar.

A forwarded message may have:
- no address rewrite causing SPF= FAIL but no masking of the originator=C2=A0address,=C2=A0
- tran= sparent address rewrite using SRS or ARC, or=C2=A0
- non-transpar= ent replacement of prior SMTP and/or From addresses, without SRS or ARC clu= es being included (as this list).

Consequently, th= e only reliable way to detect an untrusted source behind a forwarder is to = evaluate the entire message header chain.=C2=A0 =C2=A0

=
Blacklisting
---------------
For purposes of filte= ring unwanted messages, verifiable header data is not required.=C2=A0 =C2= =A0(If someone wants to spoof an untrusted sender, I am happy to consider t= hat spoofer untrusted also.)=C2=A0 =C2=A0The Received chain can be checked = for IP addresses and DNS names with negative reputation.=C2=A0 =C2=A0Simila= rly, any Received-SPF, Authentication-Results, ARC-Authenticated-Results, A= uthenticated-As or similar headers can be checked for email domain names wi= th negative reputation.=C2=A0 =C2=A0All of this can and should be done rega= rdless of the SPF and DMARC status, because SPF and DMARC are designed arou= nd direct mail flows, and SPF and DMARC pass can be achieved by pretending = to be a direct mail flow.

An additional test is to= count the number of organizations that handled the message along the deliv= ery path.=C2=A0 =C2=A0 First, consolidate out the Received=C2=A0headers wit= h private IPs or loopback IPs, then (probably) drop any messages transferre= d over LMTP, and any transfers where the ReverseDNS and HELO domains are un= changed in the handoff.=C2=A0 =C2=A0What should be left is a small number o= f entries where the FROM information indicates the IP and hostnames of the = sending organization and the HELO name should be an MX of the receiving org= anization.=C2=A0 =C2=A0(SPF checks and Forward-confirmed DNS checks can the= n be performed on this data.)=C2=A0 =C2=A0

For dir= ect messages, I assume that the maximum number of organization boundaries s= hould be three:=C2=A0 =C2=A0
- Cloud-based SMTP submitting client= to mailstore organization,=C2=A0
- mailstore organization to clo= ud-based outbound filtering service,=C2=A0
- then outbound filter= ing service to destination domain.=C2=A0 =C2=A0=C2=A0
Additionall= y, the cloud-based outbound filtering services are relatively few and well = known, which should simplify determining whether an intermediate organizati= on is a filtering service or a forwarding service.=C2=A0

It seems axiomatic that a forwarder will have an unreliable reputati= on with recipients.=C2=A0 =C2=A0If the forwarder blocks a message, the reci= pient system will not directly know that it was blocked, whether the blocke= d message was wanted or unwanted.=C2=A0 =C2=A0But if the forwarder allows a= message that the recipient does not want, the forwarder takes a hit on its= reputation.=C2=A0 =C2=A0An automated forwarding service has an incentive t= o avoid false positives, so it is almost certain to have a spam filtering p= olicy which is weaker than the final recipient system.=C2=A0 =C2=A0 Rather = than blaming the forwarding service for unwanted messages getting through, = the evaluator should look at the entire received chain.

Whitelisting
---------------
It is much riskier t= o perform whitelisting based on the header data, because one must allow for= the possibility that a nation-state attacker will construct a convincing b= ut fraudulent header chain, if they perceive that doing so will succeed.=C2= =A0 =C2=A0But I cannot imagine whitelisting a message from a random forward= er based on header data alone.=C2=A0 I would only do that if the forwarding= service, message originator, and forwarding path were well understood from= external sources.=C2=A0 =C2=A0In that case, a message from a well-identifi= ed forwarding service with a sufficiently-identified message originator mig= ht be a candidate for whitelisting.=C2=A0 =C2=A0But those situations seem l= ikely to be rare.

Conclusion
-------= --------
The overall conclusion is that if a message's only n= egative indicator is an authentication failure, the best practice would be = to send it to administrative=C2=A0quarantine for local=C2=A0policies to be = tailored to the situation.=C2=A0 =C2=A0It seems foolish to block a message = if sender authentication failure is the only problem,=C2=A0unless domain ab= use is actually confirmed during the quarantine review.=C2=A0 =C2=A0It seem= s even more foolish to filter only on the=C2=A0 identities provided by the = submitting node, without evaluating the entire header structure.
=
The unfortunate part of all this is that I suspect very few = commercial products evaluate the entire header.=C2=A0 Does anyone have data= on this question?

Where full scans are not implem= ented now, switching to a full scan will=C2=A0 significantly increase the p= rocessing overhead per message,=C2=A0which will impact throughput.

Doug Foster



<= div class=3D"gmail_quote">
On Sun, Dec= 20, 2020 at 12:10 PM Todd Herr <todd.herr=3D40valimail.com@dmarc.ietf.org> wrote:
On Fri, Dec 18, 2020 at 4:55 PM Michael Thomas <mike@mtcc.com> wrote:
=
=20

I'm not sure there's anything actionable about DMARC= 's policy values.

you mean p=3Dquarantine, or p=3D* in general?


Depending on the level of sophistication of a recei= ving email system, a given email message can have dozens of signals (or dat= a points) associated with it, of which the relevant DMARC policy record, if= it exists, is one. Those signals can all be actionable, individually or co= llectively, or ignored entirely, in that receiving system's decision to= accept or reject the message, and if it accepts it, the decision of where = to place that message.

If an applicable DMARC poli= cy record exists for the RFC5322.From domain in a message, the receiver can= :
  • Perform the necessary authentication checks for DMARC v= alidation, and use those validation results and the p=3D value as the sole = or primary determining factor in how to handle the message, strictly applyi= ng the p=3D value in cases where it's not 'none' and validation= checks fail
  • Perform the necessary authentication checks for DMARC = validation, and use those validation results and the p=3D value as the sole= or primary determining factor in how to handle the message, loosely applyi= ng the p=3D value in cases where it's not 'none' and validation= checks fail (e.g., placing the message in the spam folder even if p=3Dreje= ct is specified in the policy record)
  • Perform the necessary aut= hentication checks for DMARC validation, and use those validation results a= nd the p=3D value as one data point in a larger data set in how to handle t= he message
  • Ignore the DMARC policy record entirely


Obviously indirect mail flows, such as mailing lists and forwarding, complicate matters greatly here, as the handling by the intermediary host(s) can and will lead to a higher percentage of authentication failures. The community has attempted to mitigate this problem; RFC5322.From header rewriting, RFC5321.From header rewriting (e.g., SRS), and ARC are among the attempts put forth so far, but none have been deemed The Solution(tm) yet. In my opinion, ARC has promise, because if a message reaches me as a receiver or even intermediary and fails the authentication checks I perform, ARC header sets in the message can tell me whether or not such checks passed at previous hops *if I trust the entities that inserted those ARC header sets*. In an earlier thread, I floated an idea about ARC sealer reputation, but it didn't draw much response, so I'll float it here aga= in in the hopes that it does.

We've always been able to check the reputation of lists that resign the message. The reputation is the previously (un)solved problem.


Lists are a specific instance of the= more general case of indirect mail flows.=C2=A0

A= ny intermediate host can ARC seal and ARC-sign (a term I use as distinct fr= om re-sign) a message, an act that is meant to capture the results of authe= ntication checks done when it reached the intermediary. Whether or not the = receiver trusts those results (especially those results that claim that aut= hentication checks passed at the intermediary) when the message reaches the= receiver depends on the intermediary's reputation for being a truthful= sealer and signer, meaning whether or not it has established a history of = capturing authentication results that are true and accurate.=C2=A0

Since the receiver typically can't perform the same ch= ecks under the same conditions that existed when the intermediary performed= them (if it could, we wouldn't need something like ARC) then the recei= ver has to decide if the message is consistent with messages it's previ= ously seen through direct mail flows using that same authenticated identity= that was captured by the intermediary in the ARC header set.=C2=A0

If the indirect mail flow looks like the direct mail flow= , then the sealer is showing evidence that it can be trusted, and so the in= direct mail flow can receive the same treatment by the receiver that it wou= ld give to the direct mail flow associated with the authenticated identity.= =C2=A0

If the indirect mail flow looks different t= han the direct mail flow, then the receiver can either decide to not trust = the sealer and so treat the indirect mail flow as unauthenticated, or perha= ps it can dig into matters further to see why the difference exists. A mail= ing list, for example, that has subscribers whose domain is a consumer mail= box provider might just show an indirect mail flow for that domain to the r= eceiver that has a substantially better overall reputation than the direct = mail flow for that domain to the receiver; rather than letting this differe= nce impact the level of trust in its sealing reputation that a receiver wou= ld assign to the list, it may very well have to put in an override to its s= ystem for tracking sealer trust.

--=C2=A0

Todd Herr | Sr. Technical Prog= ram Manager
p:= 703.220.4153


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

_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
--000000000000a964fd05b6eb8874-- From nobody Sun Dec 20 14:01: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 4842E3A11FA for ; Sun, 20 Dec 2020 14:01:24 -0800 (PST) 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 0CI8-dC5No-E for ; Sun, 20 Dec 2020 14:01:22 -0800 (PST) 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 E0CB73A11F6 for ; Sun, 20 Dec 2020 14:01:20 -0800 (PST) Received: from localhost.junc.eu (localhost.junc.eu [127.0.0.1]) by mx.junc.eu (Postfix) with SMTP id 34EB97FED2 for ; Sun, 20 Dec 2020 22:01:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junc.eu; i=@junc.eu; l=715; q=dns/txt; s=default; t=1608501677; h=from : subject : date : to; bh=QHspFE4eMjigSVznX0Vloz6pLpN6UpDFY3Dnwz1RY5I=; b=Cw0MhwGh+XMSW+UKkqgQwRIUw/cLenrtjQ9/dhHt/gaTvsmaHpYRludAF7oL3Ah9UUoWn ANH2E5oLVlu/WJBTyB8ePNqLoxeQ6fMBM2YTu8d0tN2TthlebNL7Gsm+MUw+KtzUfhTFvil hSEjxXPyT1zALJTt1pJexKtRWsxtHhI= Received: from localhost.junc.eu (localhost.junc.eu [IPv6:::1]) by mx.junc.eu (Postfix) with ESMTPSA id 180577FE44 for ; Sun, 20 Dec 2020 22:01:17 +0000 (UTC) MIME-Version: 1.0 Date: Sun, 20 Dec 2020 23:01:17 +0100 From: Benny Pedersen To: dmarc@ietf.org In-Reply-To: References: <1e61f7c4-c6d2-5dab-dfc7-f1fd740e1d0d@tana.it> <20201219194954.BF87E2ADF1FB@ary.qy> <9b7cc1c9-e031-4ef8-8d92-2c16cc4fa073@tana.it> User-Agent: Roundcube Webmail/1.4.8 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] ARC vs p=quarantine X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 20 Dec 2020 22:01:24 -0000 On 2020-12-20 19:13, John R Levine wrote: > On Sun, 20 Dec 2020, Alessandro Vesely wrote: >>> question is who steps up to provide such shared lists. >> >> Dnswl.org counts about 25K domains. > > I suppose one might try them but I expect most of them are not sending > forwarded mail. only sending to maillists here that breaks dkim and do not add arc before breaking dkim, world of 2020 cant be better :=) > I've finally gotten around to doing ARC checks in my SMTP daemon so I > can see who's adding ARC seals. hopefully maillists stops dkim signing, its the incorrect place to solve breaking dkim now that nearly all maillists i am on have showed what not to do, its hopefully solved soon From nobody Sun Dec 20 14:07: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 10BFA3A1204 for ; Sun, 20 Dec 2020 14:07:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, 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=mtcc.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 sBzUtzqm2zZj for ; Sun, 20 Dec 2020 14:07:35 -0800 (PST) Received: from mail-pg1-x530.google.com (mail-pg1-x530.google.com [IPv6:2607:f8b0:4864:20::530]) (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 284B53A11FF for ; Sun, 20 Dec 2020 14:07:34 -0800 (PST) Received: by mail-pg1-x530.google.com with SMTP id v29so5157185pgk.12 for ; Sun, 20 Dec 2020 14:07:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mtcc.com; s=fluffulence; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=gZ6s2HZ21jql/AHIjyhCYaAZh9CKxIxdC3f+GnOTgzI=; b=K/Zbn8x8dMKt+zFUMzXn7qwW1rsJfPHpozZAJkzuQEna0HNoj4eeRAWni+e1LUrzDV qimLnULNlItCWEKdX8dEtaBx6qdkGzR1bjGx1MwovXy32iOHI/shAKbsFUTQmwVegt0U v1hDHuXAYBCzw/Ng88MFV3gbdokHHlNcMAnAVzoBqcbVnSBwTQmNjOWdJje9rjFdd37T n0y7SVxeSUBCLc7XvsbpSdIoRc3wgX7XDnUwm4esbHJ8QDT5qo4sVM0Klp7HDIOJ06z5 Va3z59dP6Yg/Kn5v4gCCSyfl250S89nsLP/+nE0NcjvowJdI5zPfGrrIat/VkF+co8r6 lGzg== 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=gZ6s2HZ21jql/AHIjyhCYaAZh9CKxIxdC3f+GnOTgzI=; b=tf0kpy7ShIEFJdLTtb+m61l1UJqozSUplNSOZaMOOsn/ugVy4P1j5hG5Wh74ab62z+ Uwp8+VDSExmTnPZeKKD2RcLDZv0BGP1cwNK+KE03UW33nTr6rJ2uBg14SnpDCuxlrwtD tllcKEHyJqr/YOVLVobmK4QfriVrVaO06LScH+ymdtF0D7Wwo344Ks1OOqOJDHP0Sd2N u37VTb7/ysjUW/SofY1yQLQ/zx8Ag3s9H8a51zG8DvmzPro0La4ULrJAzKFQffyb0o7d 8MHFkH3fa0rFoubuwp6HT5aIDP/xt3SJ4Xn9sA2/Yx0EdVl2yVY42ZPAwgW5NdUH5yYz Zmzw== X-Gm-Message-State: AOAM531zJlVcXq5JYhPEndyh8W5hcsZ4MwtLlo746ER/FjJg2b+k4xdU l393CbAA08jVHL7dqzl4zC1u12LSsX1jzw== X-Google-Smtp-Source: ABdhPJyXjHA5aU3P7tmrGKrHJI0UBORwcuevkUyw71wBZo0usrRQz9Ya3bKN9i2XZ6OAj6jpP8jdCg== X-Received: by 2002:a63:ea01:: with SMTP id c1mr12665262pgi.138.1608502054112; Sun, 20 Dec 2020 14:07:34 -0800 (PST) Received: from mike-mac.lan ([107.182.37.0]) by smtp.gmail.com with ESMTPSA id t8sm2683197pgl.70.2020.12.20.14.07.32 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 20 Dec 2020 14:07:33 -0800 (PST) To: dmarc@ietf.org References: <1e61f7c4-c6d2-5dab-dfc7-f1fd740e1d0d@tana.it> <20201219194954.BF87E2ADF1FB@ary.qy> <9b7cc1c9-e031-4ef8-8d92-2c16cc4fa073@tana.it> From: Michael Thomas Message-ID: Date: Sun, 20 Dec 2020 14:07:31 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.5.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] ARC vs p=quarantine X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 20 Dec 2020 22:07:36 -0000 On 12/20/20 2:01 PM, Benny Pedersen wrote: > > hopefully maillists stops dkim signing, its the incorrect place to > solve breaking dkim Sorry, ARC is warmed over DKIM, and an experiment. DKIM is a full internet standard and expressly intended for lists, etc to resign if they broke the original DKIM signature. We have always had the ability to do reputation checks regardless of ARC. I'm not sure when this wg lost sight of that. Mike From nobody Sun Dec 20 16:52: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 7A73E3A0934 for ; Sun, 20 Dec 2020 16:52:15 -0800 (PST) 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 x-PG6n-gFMsM for ; Sun, 20 Dec 2020 16:52:13 -0800 (PST) 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 833C23A0927 for ; Sun, 20 Dec 2020 16:52:13 -0800 (PST) Received: from localhost.junc.eu (localhost.junc.eu [127.0.0.1]) by mx.junc.eu (Postfix) with SMTP id 9E100800EE for ; Mon, 21 Dec 2020 00:52:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junc.eu; i=@junc.eu; l=843; q=dns/txt; s=default; t=1608511931; h=from : subject : date : to; bh=MlZ7s7KqXt76hQc3pRmSbsRgSZuueyLH8/3X4lT9vNg=; b=JC7Htd0LU3J8NW26ed1PSc2++4i8hVzp2DUKFQtqbzJB0SI+TFcVa+bU4Hsf2AkUsIS4S TUCy1D44/EJKTr9ZPtMMAgXZH2LhagkvYAPjSw19rPPKU5bNWYEiaeQtd5H2d31ujDy+cag yOm3sR1vCJGap/H/3CH/N0rMck4SbuU= Received: from localhost.junc.eu (localhost.junc.eu [IPv6:::1]) by mx.junc.eu (Postfix) with ESMTPSA id 804EC7FC9B for ; Mon, 21 Dec 2020 00:52:11 +0000 (UTC) MIME-Version: 1.0 Date: Mon, 21 Dec 2020 01:52:11 +0100 From: Benny Pedersen To: dmarc@ietf.org In-Reply-To: References: <1e61f7c4-c6d2-5dab-dfc7-f1fd740e1d0d@tana.it> <20201219194954.BF87E2ADF1FB@ary.qy> <9b7cc1c9-e031-4ef8-8d92-2c16cc4fa073@tana.it> User-Agent: Roundcube Webmail/1.4.8 Message-ID: <496c92bc02e75c2d7b02365d9dd0cf38@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] ARC vs p=quarantine X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 21 Dec 2020 00:52:16 -0000 On 2020-12-20 23:07, Michael Thomas wrote: > On 12/20/20 2:01 PM, Benny Pedersen wrote: >> >> hopefully maillists stops dkim signing, its the incorrect place to >> solve breaking dkim > > > Sorry, ARC is warmed over DKIM, and an experiment. DKIM is a full > internet standard and expressly intended for lists, etc to resign if > they broke the original DKIM signature. We have always had the ability > to do reputation checks regardless of ARC. I'm not sure when this wg > lost sight of that. only original senders should dkim sign, rest should only arc sign, i dont have to agre on anyhing other then that, if maillists dkim sign thay try to steel the original dkim private key without succes, and there is possible a solotion to dmarc adsp handling this break seeing eitf do 3 dkim sign just to be sure it does not work From nobody Mon Dec 21 09:19: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 397863A1256 for ; Mon, 21 Dec 2020 09:19:15 -0800 (PST) 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, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 kKbke0IllDFB for ; Mon, 21 Dec 2020 09:19:13 -0800 (PST) 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 467A13A1250 for ; Mon, 21 Dec 2020 09:19:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1608571148; bh=6ly7n69J4SF9KvGPqCd3Eezmh6TJDmA6r69+FrTWsU4=; l=1366; h=To:References:From:Date:In-Reply-To; b=CO82FRnL6VUjM8YoyFX4Bj/i8321He9fZeG5hHqYdHvEVbzW/y6gHMgLLkX8QpwS+ Co9SoTDq/4LDkEsY2wW1rDSnFJ4snqEUNSKICH32/ENlOMKdYMt3GJ/rxPN1sp71S3 s6McJTArFbBZZt6qAE/GiTzojwhz6pdZlJ+UnEnFWACuiJmd8vdDswM56UsoK Authentication-Results: tana.it; auth=pass (details omitted) Original-From: Alessandro Vesely 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 00000000005DC07E.000000005FE0D90C.000065CF; Mon, 21 Dec 2020 18:19:08 +0100 To: John R Levine , dmarc@ietf.org References: <20201218023900.E73B82ACBB2B@ary.qy> <4a43ffaa-3987-c892-cce7-56f18888cdf5@tana.it> <39125012-e356-d62d-36fd-a7ff25a9f59f@taugh.com> <6bba023-d3d9-63a5-8441-11dac9a05e28@taugh.com> From: Alessandro Vesely Message-ID: <74051a64-871a-db72-b5d9-1be374e23015@tana.it> Date: Mon, 21 Dec 2020 18:19:08 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: <6bba023-d3d9-63a5-8441-11dac9a05e28@taugh.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] Ticket #55 - Clarify legal and privacy implications of failure reports X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Dec 2020 17:19:15 -0000 On Sun 20/Dec/2020 19:17:03 +0100 John R Levine wrote: >> On Fri 18/Dec/2020 21:05:43 +0100 John R Levine wrote: >>> [ failure reports leak PII including forwarded recipients ] > >> Are failure reports about forwarded messages still useful?  If not so much, >> perhaps we could deplore them. > > There's no mechanical way to tell whether a message has been forwarded as > opposed to bcc or a mailing list or a local redistribution list or whatever. One could judge by verified SPF alignment. Such kind of gross misconfiguration can be detected by aggregate reports, so disabling RUF doesn't seem to be an irrecoverable loss. > Given how few sites send failure messages, and that we all seem able to manage > our DMARC setups without them, I don't think they're worth a lot of effort. > Hence my suggestion for simplified advice. Agreed. However, cutting down sending times might be reassuring. >> Keeping the target of forwarded messages private needs to be addressed at >> emailcore as well, though.  Regular bounces leak the same info. > > That seems like a great way to destroy mailing lists by not telling them which > recipients are bouncing. Temporary failures (over quota) don't hurt mailing lists. Permanent failures (target account takedown) deserve bounces right from the forwarding address. Best Ale -- From nobody Mon Dec 21 09:27: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 964FB3A12B3 for ; Mon, 21 Dec 2020 09:27:07 -0800 (PST) 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, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 bfXSZ-nSTl7P for ; Mon, 21 Dec 2020 09:27:06 -0800 (PST) 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 6A5933A12AE for ; Mon, 21 Dec 2020 09:27:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1608571624; bh=gNm12orwdMpxytquFfuf5saAwDTuTZ4p/HjEqSMqVko=; l=1445; h=To:References:From:Date:In-Reply-To; b=CSsEXVzyHjUufZJjlpyPAYzEk3GWYvEhWHGloDYDPB6Ir+SA0hQZUL3JHKeT/quOl b3g5jU6/jL9O97VqMTx2KnDDXiZTgHNrRcXR9ehnyljeZroMz7Coly/0pFhQMlIVcO 96KA8Efx3HrWqGG45wqZTdtOr+IxqEL1iPRbz6cQnM5zHXMPEhvYjxjhf3n5E Authentication-Results: tana.it; auth=pass (details omitted) Original-From: Alessandro Vesely 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 00000000005DC0D1.000000005FE0DAE8.000066CE; Mon, 21 Dec 2020 18:27:04 +0100 To: dmarc@ietf.org References: <1e61f7c4-c6d2-5dab-dfc7-f1fd740e1d0d@tana.it> <20201219194954.BF87E2ADF1FB@ary.qy> <9b7cc1c9-e031-4ef8-8d92-2c16cc4fa073@tana.it> <496c92bc02e75c2d7b02365d9dd0cf38@junc.eu> From: Alessandro Vesely Message-ID: <8c6c4f7f-4a95-cd2b-306e-83a50dcde385@tana.it> Date: Mon, 21 Dec 2020 18:27:04 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: <496c92bc02e75c2d7b02365d9dd0cf38@junc.eu> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] ARC vs p=quarantine X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 21 Dec 2020 17:27:08 -0000 On Mon 21/Dec/2020 01:52:11 +0100 Benny Pedersen wrote: > On 2020-12-20 23:07, Michael Thomas wrote: >> On 12/20/20 2:01 PM, Benny Pedersen wrote: >>> >>> hopefully maillists stops dkim signing, its the incorrect place to solve >>> breaking dkim >> >> Sorry, ARC is warmed over DKIM, and an experiment. DKIM is a full >> internet standard and expressly intended for lists, etc to resign if >> they broke the original DKIM signature. We have always had the ability >> to do reputation checks regardless of ARC. I'm not sure when this wg >> lost sight of that. > > only original senders should dkim sign, rest should only arc sign, i dont have > to agre on anyhing other then that, if maillists dkim sign thay try to steel > the original dkim private key without succes, and there is possible a solotion > to dmarc adsp handling this break > > seeing eitf do 3 dkim sign just to be sure it does not work For the message I'm replying to, I got: Authentication-Results: wmail.tana.it; spf=pass smtp.mailfrom=ietf.org; dkim=pass reason="Original-From: transformed" (whitelisted) header.d=junc.eu; dkim=pass (whitelisted) header.d=ietf.org header.b=GUNfiCpP; dkim=fail (signature verification failed, whitelisted) header.d=ietf.org header.b=IIMQxhd+ Two out of three is not bad, is it? If IETF only did ARC seals, I'd probably verified no signature at all —since I don't run ARC checks. Best Ale -- From nobody Mon Dec 21 09:28: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 63F6D3A12CA for ; Mon, 21 Dec 2020 09:28:13 -0800 (PST) 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 (2048-bit key) header.d=iecc.com header.b=cXJDdNIw; dkim=pass (2048-bit key) header.d=taugh.com header.b=EFop4NhZ Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OaX4EKR7r9am for ; Mon, 21 Dec 2020 09:28:10 -0800 (PST) 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 C74123A12C7 for ; Mon, 21 Dec 2020 09:28:09 -0800 (PST) Received: (qmail 87169 invoked from network); 21 Dec 2020 17:28:07 -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=1547f.5fe0db27.k2012; i=johnl-iecc.com@submit.iecc.com; bh=0stTCGSw18EDbcX803nVswxdrdZgRMs20i0XUvTgx0M=; b=cXJDdNIwNA5NIN1drVS4+pefCrNDF7qZBsPkTLBxDaPXfb8Nz6I2UKBP23IZ506LFSlroNK57inixik07TJCNJSlfzJWAe3k7g0zkiNX1ZrQJhtqwVNu1avZ+voUT0UIbeDVxV0CVokDDAikTWstSmK6ppSmH5QUwg6R1SHNaGeNP383Peo1CToBeC/X2pmqyAl75ptvXX8FCx1jsQ7YcSXqTQfg61Y3zS8yyWoH5UU5NE5bsVLdKAD4ajVhb9z3Qjq9+oRpgnNegGbsuqt6aB0vmdAmrChOivAacJEpH3BFlBATHiEdLH3oPcS7ylOmqilOeGZgX2TiCVoKnWpjXg== 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=1547f.5fe0db27.k2012; olt=johnl-iecc.com@submit.iecc.com; bh=0stTCGSw18EDbcX803nVswxdrdZgRMs20i0XUvTgx0M=; b=EFop4NhZ2mNCNYdgOuQYP24aD8ThCQewNg5YQ32jLvGXsSjmWeBs0FlBjXQQKh5QJxBslGRdoMANbL2bFDpoh88b89qZVTHHtNpCPE2CQKy/ctl+a2cO/VIyISkQM2GIr8QPheSH1dYQZCGOHJVJPeOLlDb9ZN+qQsl5uSb+eDuTOCTjEB1T3SAoaovZgSO08qsx6SCQKm0TUyUId/Ouq3RjaU41v38QAlE+Vk3gW4pyWrmmmlfm+e1UKRQ6mQtk6p2H4T2HohHVrxFb2+Cbut8wuFEqpkrv3ICYCjqdifApuo5JMtO6aLY0At/CPXc/smDrT8Uwo5YB+5GMLJuhYg== Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPSA (TLS1.3 ECDHE-RSA AES-256-GCM AEAD, johnl@iecc.com) via TCP6; 21 Dec 2020 17:28:06 -0000 Date: 21 Dec 2020 12:28:06 -0500 Message-ID: From: "John R Levine" To: "Alessandro Vesely" , dmarc@ietf.org In-Reply-To: <74051a64-871a-db72-b5d9-1be374e23015@tana.it> References: <20201218023900.E73B82ACBB2B@ary.qy> <4a43ffaa-3987-c892-cce7-56f18888cdf5@tana.it> <39125012-e356-d62d-36fd-a7ff25a9f59f@taugh.com> <6bba023-d3d9-63a5-8441-11dac9a05e28@taugh.com> <74051a64-871a-db72-b5d9-1be374e23015@tana.it> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="0-1641124163-1608571686=:40463" Archived-At: Subject: Re: [dmarc-ietf] Ticket #55 - Clarify legal and privacy implications of failure reports X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Dec 2020 17:28:13 -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-1641124163-1608571686=:40463 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT On Mon, 21 Dec 2020, Alessandro Vesely wrote: >>> Keeping the target of forwarded messages private needs to be addressed at >>> emailcore as well, though.  Regular bounces leak the same info. >> >> That seems like a great way to destroy mailing lists by not telling them >> which recipients are bouncing. > > Temporary failures (over quota) don't hurt mailing lists. Permanent failures > (target account takedown) deserve bounces right from the forwarding address. Um, the mailing list *is* the forwarding address. In any event, I think we agree that failure reports are not worth a lot of effort here. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly --0-1641124163-1608571686=:40463-- From nobody Mon Dec 21 09:47: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 5C9623A131B for ; Mon, 21 Dec 2020 09:47:33 -0800 (PST) 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, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 PLmd0LWx5LXP for ; Mon, 21 Dec 2020 09:47:32 -0800 (PST) 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 4534C3A131A for ; Mon, 21 Dec 2020 09:47:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1608572850; bh=QyzLna6/Dahj/xMLx5y3iaXOgDJl8qs5P1iu5jPZcUU=; l=1026; h=To:References:From:Date:In-Reply-To; b=Cr9LFpbQKZtgLzRMxCBuKt7Ociv6nMtVC+CkoCYgL+zor8DXNajujOSA62314Ly8j B/nvJUlLE+uDNQV4d7OVvWRXE2VJI0i1E7xq9B5HgNcRtFpECkdfnpxOExbvOJdb7S GFPetIzlahbpBn4VIbz1uNrOLadvcp//sZLj875MPkZiM32EFPuUSJgC6Cc1Z Authentication-Results: tana.it; auth=pass (details omitted) Original-From: Alessandro Vesely 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 00000000005DC07E.000000005FE0DFB2.00006928; Mon, 21 Dec 2020 18:47:30 +0100 To: dmarc@ietf.org References: <20201211173722.6B4DF29782C7@ary.qy> <02f786e5-b7cd-9a89-e3e3-73594f3bcda0@mtcc.com> From: Alessandro Vesely Message-ID: Date: Mon, 21 Dec 2020 18:47:30 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] p=quarantine X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 21 Dec 2020 17:47:33 -0000 On Sun 20/Dec/2020 18:10:03 +0100 Todd Herr wrote: > > Lists are a specific instance of the more general case of indirect mail flows. How many kinds of indirect mail flows do rewrite From:? Specific methods might prove more effective than general ones. > [...] > > Since the receiver typically can't perform the same checks under the same > conditions that existed when the intermediary performed them (if it could, we > wouldn't need something like ARC) then the receiver has to decide if the > message is consistent with messages it's previously seen through direct mail > flows using that same authenticated identity that was captured by the > intermediary in the ARC header set. Doesn't that assume some kind of omniscience at the receiver's? Consistency with previous messages by the same source is not straightforward. Using the same selector? Signing more or less the same set of header fields? Choice of vocabulary? HTML vs. plain text style (e.g. line length)? A.I.? Best Ale -- From nobody Mon Dec 21 10:06: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 BA0B93A133C for ; Mon, 21 Dec 2020 10:06:38 -0800 (PST) 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, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 yKn_fOKq86Mq for ; Mon, 21 Dec 2020 10:06:37 -0800 (PST) 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 ACB7B3A1336 for ; Mon, 21 Dec 2020 10:06:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1608573994; bh=f0DT82qNnWVY+eHmcqqwVhO8w+WknS/P3/eFzmHIGy4=; l=1071; h=To:References:From:Date:In-Reply-To; b=B7BjkpzFTk+Nl2rPcaP6wEb3HD+iErE6S56SM7ptND39YyCuI+KeD37lET1eznmfw 3W59xYysxpcN695c3BNv1jZ+3mxLcIlrL8aiIKXemRqju/swr6n1/xmdxOolutciV8 Fp27lyyJd4pjQxzqxqTNckIJTDb53gni1viseoaYqxYCUhNwdodJIc8HaaAoS Authentication-Results: tana.it; auth=pass (details omitted) Original-From: Alessandro Vesely 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.000000005FE0E42A.00006B49; Mon, 21 Dec 2020 19:06:34 +0100 To: John R Levine , dmarc@ietf.org References: <20201218023900.E73B82ACBB2B@ary.qy> <4a43ffaa-3987-c892-cce7-56f18888cdf5@tana.it> <39125012-e356-d62d-36fd-a7ff25a9f59f@taugh.com> <6bba023-d3d9-63a5-8441-11dac9a05e28@taugh.com> <74051a64-871a-db72-b5d9-1be374e23015@tana.it> From: Alessandro Vesely Message-ID: Date: Mon, 21 Dec 2020 19:06:34 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] Ticket #55 - Clarify legal and privacy implications of failure reports X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Dec 2020 18:06:39 -0000 On Mon 21/Dec/2020 18:28:06 +0100 John R Levine wrote: > On Mon, 21 Dec 2020, Alessandro Vesely wrote: >>>> Keeping the target of forwarded messages private needs to be addressed at >>>> emailcore as well, though.  Regular bounces leak the same info. >>> >>> That seems like a great way to destroy mailing lists by not telling them >>> which recipients are bouncing. >> >> Temporary failures (over quota) don't hurt mailing lists.  Permanent failures >> (target account takedown) deserve bounces right from the forwarding address. > > Um, the mailing list *is* the forwarding address. Oh, well, no, in that case the target address is not meant to be kept secret. > In any event, I think we agree that failure reports are not worth a lot of > effort here. I'd look for ways to trim them down a bit. Just enough to let them be privacy-wise credible. Besides skipping forwarded stuff (including mailing list) and an enable-by-domain feature, avoiding external addresses in ruf= could be another simplification. Not worth? Best Ale -- From nobody Mon Dec 21 10:25: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 A9CD23A1308 for ; Mon, 21 Dec 2020 10:25:52 -0800 (PST) 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 (2048-bit key) header.d=iecc.com header.b=KmVsUZpn; dkim=pass (2048-bit key) header.d=taugh.com header.b=aaBeFFG5 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Epfxmau7Nd0a for ; Mon, 21 Dec 2020 10:25:51 -0800 (PST) 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 C9BF73A1310 for ; Mon, 21 Dec 2020 10:25:50 -0800 (PST) Received: (qmail 4697 invoked from network); 21 Dec 2020 18:25:49 -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=1256.5fe0e8ad.k2012; i=johnl-iecc.com@submit.iecc.com; bh=W1SVKCZV3FToMuWn7Xh2ROhPQefnRdNL/Pzky4jaNhk=; b=KmVsUZpnhfi4HxPhEGhf1+nqol0N4xppWsnBSdJoCtb6mC44mG+hUyclG0wApFBb03LsgcHCxBoz6GupfksPxoCQsK9jlD77ceV2ghkzdcrfmBTJiqbL/tFOgxtVto55MSeFAyLMXsIS1YTBoGe6HMSd0CNYPupMKpWyOywJ+pP3s7ljNmlAmfmh12BSLAMH+8RK7zl35TpmzSI0QgWgZdWOQKYSBfFVEBkeDZ8D08IvvyoCKxA4tnUxMwH6gRdiIQhFOdoQmxXZfvIwCbhG+l9JyW/bJVPxNnRJjK584xxNvs63hd21WdFycegJ+ia9tsi2n6lwxMPUlFHUCWimkg== 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=1256.5fe0e8ad.k2012; olt=johnl-iecc.com@submit.iecc.com; bh=W1SVKCZV3FToMuWn7Xh2ROhPQefnRdNL/Pzky4jaNhk=; b=aaBeFFG5d0ZQCJeYD/hdDxCp5zUIT87DnZq80hs0y5ac+GF8roL5PUZ64Oe4OkVc1jQWMc8ErDOMVqDGFfgZZ8mgh2Sp16o2XGsXdNyx2xfBWXJY29aysW7DSph1lKPc83dqgnYPf961qDiVI5AgOGEk4+McIwUmaqsQeOyBNn3b2GKrlYdSxzZwpJbmf0VsD+bYZgWbGGuQkNMpIHoFPNRsrGDKgqDCUUxO1G8jiOPNuDL8J8Fwsnhiu4SP7cOCj/OQeMB3Pnunac/9gR2qOsJX9A0uQ1h7OCaQcKQp2/CgGo9b1UaigX1N0X9BK27iYlpxiFUbknavKm6e55gV+Q== Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPSA (TLS1.3 ECDHE-RSA AES-256-GCM AEAD, johnl@iecc.com) via TCP6; 21 Dec 2020 18:25:48 -0000 Date: 21 Dec 2020 13:25:48 -0500 Message-ID: From: "John R Levine" To: "Alessandro Vesely" , dmarc@ietf.org In-Reply-To: References: <20201218023900.E73B82ACBB2B@ary.qy> <4a43ffaa-3987-c892-cce7-56f18888cdf5@tana.it> <39125012-e356-d62d-36fd-a7ff25a9f59f@taugh.com> <6bba023-d3d9-63a5-8441-11dac9a05e28@taugh.com> <74051a64-871a-db72-b5d9-1be374e23015@tana.it> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [dmarc-ietf] Ticket #55 - Clarify legal and privacy implications of failure reports X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Dec 2020 18:25:53 -0000 >>>> That seems like a great way to destroy mailing lists by not telling them >>>> which recipients are bouncing. >> >> Um, the mailing list *is* the forwarding address. > > Oh, well, no, in that case the target address is not meant to be kept secret. You don't know that. Keeping in mind that the reports go the the From: address, some lists let subscribers see who else is subscribed, but many do not. >> In any event, I think we agree that failure reports are not worth a lot of >> effort here. > > I'd look for ways to trim them down a bit. Just enough to let them be > privacy-wise credible. As I would have thought was evident by now, there is no such thing. We have no idea what parts of the message might disclose PII, and we have no idea what relationship (if any) the targer of the ruf= might have to the author of the messsage. We can just note that ruf can leak personal info and leave it at that. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From nobody Mon Dec 21 10:57: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 21CBE3A1271 for ; Mon, 21 Dec 2020 10:57:44 -0800 (PST) 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, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 VEYh5h3XB9-T for ; Mon, 21 Dec 2020 10:57:42 -0800 (PST) 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 9D2CC3A1266 for ; Mon, 21 Dec 2020 10:57:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1608577059; bh=/A+zij/PSPHFvcF8lXfxk5twD/aHUx06JhvdtkyZZYo=; l=1856; h=To:References:From:Date:In-Reply-To; b=BxYBQGH2FkinCKNqVa+XFu1+52RGRCpJ7CHkr9D0iXS1HHsR9ttoqWGVTywCD+/P1 zH8dEvwRbCqJmHFCACeZ4bQNUQm/5hZFKrCufzK3/S655Q+OKQZuG6bm9nMN1fVzrF mAuwJgXiNc190aQ3PYJfiXMV+RSzpp7O43WQIw3BztsbAHYjiF5ld19VXhibZ Authentication-Results: tana.it; auth=pass (details omitted) Original-From: Alessandro Vesely 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.000000005FE0F023.00007121; Mon, 21 Dec 2020 19:57:39 +0100 To: John R Levine , dmarc@ietf.org References: <20201218023900.E73B82ACBB2B@ary.qy> <4a43ffaa-3987-c892-cce7-56f18888cdf5@tana.it> <39125012-e356-d62d-36fd-a7ff25a9f59f@taugh.com> <6bba023-d3d9-63a5-8441-11dac9a05e28@taugh.com> <74051a64-871a-db72-b5d9-1be374e23015@tana.it> From: Alessandro Vesely Message-ID: <3034face-b6fc-0ce2-fa1b-f59210bd6f5b@tana.it> Date: Mon, 21 Dec 2020 19:57:38 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] Ticket #55 - Clarify legal and privacy implications of failure reports X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Dec 2020 18:57:44 -0000 On Mon 21/Dec/2020 19:25:48 +0100 John R Levine wrote: >>>>> That seems like a great way to destroy mailing lists by not telling them >>>>> which recipients are bouncing. >>> >>> Um, the mailing list *is* the forwarding address. >> >> Oh, well, no, in that case the target address is not meant to be kept secret. > > You don't know that.  Keeping in mind that the reports go the the From: > address, some lists let subscribers see who else is subscribed, but many do not. Sorry for my lack of details. I was considering the cases where a bounce or a failure report reveal that user@example.com forwards to user@secret.example. That is, a user may want to receive mail destined to her (old) address, but does not want (old) contacts to become aware of her new one. The address she uses to subscribe to a mailing list is obviously revealed to the MLM. It is not secret in that sense. >>> In any event, I think we agree that failure reports are not worth a lot of >>> effort here. >> >> I'd look for ways to trim them down a bit.  Just enough to let them be >> privacy-wise credible. > > As I would have thought was evident by now, there is no such thing.  We have no > idea what parts of the message might disclose PII, and we have no idea what > relationship (if any) the target of the ruf= might have to the author of the > message.  We can just note that ruf can leak personal info and leave it at that. What is evident is that, as conceived, failure reports break privacy enough to make an admin's skin crawl. I think we should convey the fact that failure reports are (to be) sent in limited circumstances and with due circumspection. We must underline that in order to differentiate failure from aggregate reports, lest people conclude that feedback reporting is a bad idea in general. Best Ale -- From nobody Mon Dec 21 13:01: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 627413A11A3 for ; Mon, 21 Dec 2020 13:01:48 -0800 (PST) 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 (2048-bit key) header.d=iecc.com header.b=tYdr8+1W; dkim=pass (2048-bit key) header.d=taugh.com header.b=QijfuSTC Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23NRV6fwJuXK for ; Mon, 21 Dec 2020 13:01:46 -0800 (PST) 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 50EB13A118F for ; Mon, 21 Dec 2020 13:01:45 -0800 (PST) Received: (qmail 50511 invoked from network); 21 Dec 2020 21:01:45 -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=c54d.5fe10d39.k2012; i=johnl-iecc.com@submit.iecc.com; bh=DxcSO4B433abeG6/SFn3Iz2jldlYc03rh2jyY0wq61k=; b=tYdr8+1W5xPmpvIoJebXBINaH1YD6a6DvIPQezqUPaRzUCi5Xix6N1PPpKIcdvFAi9koMVnQdhn8I41ikD3ZQhCvEdLrrsHsC4tdytlZi3nPsVHyn1my1elK9ZMK102fxAnmhhKYz79aG0IW0s4AH6GzJEviKFR6kl0V2QmNrr3CjrOYOvQzXSFghSdy5nG2TEi6VSrHPEGqkUh5+8WSo5LVtYKfUM/2PfrKPVJEBk0xmgjT2xVpb57UteCWweDlxQoaX5PvAZa+9c0I8zUEPk4qORQ6xJFjgEGZyHoFTgWP3SZb9BEBxvFZTaWXH7CPNfxpolDHk5nvb68mT/T4kA== 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=c54d.5fe10d39.k2012; olt=johnl-iecc.com@submit.iecc.com; bh=DxcSO4B433abeG6/SFn3Iz2jldlYc03rh2jyY0wq61k=; b=QijfuSTCVWygAWcuhSrqn/KewSf8MAiTY6oizMi2fgSr6X1got3qn+SZu76E/neBXy8yPBjSDDfi7TGicWH+sEsOGDuX33MlRlY9s+KvRCiklgu3K3H+bupaXsWKuKGULzDqYTNwPxEilMDoDN4BIpEr0+wVyqASahPVR/IEGCCRssMBqrzQIWnEZ3g5gDVmdz29O5aTn4I4u+JwvDGhQEIIkuWlCeQ/7/fmwRooomu4Ab8KVvB/yaBA22i5Br2HaldaoES6ln4RgKkfV4Aolo5C903LEZ9tHB18EOonxECy1rtca76m9CusHmMaHKa7lb6VrPbl5ehd4KGhqRKP3Q== Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPSA (TLS1.3 ECDHE-RSA AES-256-GCM AEAD, johnl@iecc.com) via TCP6; 21 Dec 2020 21:01:44 -0000 Date: 21 Dec 2020 16:01:44 -0500 Message-ID: <46339b38-3b24-bcb7-5e73-8a97038ed69@taugh.com> From: "John R Levine" To: "Alessandro Vesely" , "John R Levine" , dmarc@ietf.org In-Reply-To: <3034face-b6fc-0ce2-fa1b-f59210bd6f5b@tana.it> References: <20201218023900.E73B82ACBB2B@ary.qy> <4a43ffaa-3987-c892-cce7-56f18888cdf5@tana.it> <39125012-e356-d62d-36fd-a7ff25a9f59f@taugh.com> <6bba023-d3d9-63a5-8441-11dac9a05e28@taugh.com> <74051a64-871a-db72-b5d9-1be374e23015@tana.it> <3034face-b6fc-0ce2-fa1b-f59210bd6f5b@tana.it> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [dmarc-ietf] Ticket #55 - Clarify legal and privacy implications of failure reports X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Dec 2020 21:01:48 -0000 > Sorry for my lack of details. I was considering the cases where a bounce or > a failure report reveal that user@example.com forwards to > user@secret.example. That is, a user may want to receive mail destined to her > (old) address, but does not want (old) contacts to become aware of her new > one. The address she uses to subscribe to a mailing list is obviously > revealed to the MLM. It is not secret in that sense. You keep confirming what I am saying. The failure report from user@secret.example would go to the report receiver of whoever sent the message in the first place if the MLM doesn't munge From, or to the MLM if it does. Either way, it's leaking PII. > What is evident is that, as conceived, failure reports break privacy enough > to make an admin's skin crawl. Right. > I think we should convey the fact that failure reports are (to be) sent in limited circumstances and with due > circumspection. Yes, that is more or less what I have been saying, only I'd say you probably don't want to send them at all since they have turned out not to be important. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From nobody Mon Dec 21 18:37: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 E6C913A0858 for ; Mon, 21 Dec 2020 18:37:56 -0800 (PST) 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 GVJtgMwdd6-y for ; Mon, 21 Dec 2020 18:37:54 -0800 (PST) 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 7A4013A0855 for ; Mon, 21 Dec 2020 18:37:53 -0800 (PST) Received: from localhost.junc.eu (localhost.junc.eu [127.0.0.1]) by mx.junc.eu (Postfix) with SMTP id 3498880519 for ; Tue, 22 Dec 2020 02:37:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junc.eu; i=@junc.eu; l=936; q=dns/txt; s=default; t=1608604672; h=from : subject : date : to; bh=qillzelswaYhCUFohCdvhYZnjKipa5vzGHlcfDkhMCw=; b=g4EQTGEUBot2Ii9TfC4UWlAsKjuApT4EwtQHcSQnPbrnCcHSNraHmXDWzU0WIkXUaOXex 73vM0PzquEA7FV1qu9/ICyc+1Bez6SUz5zjLRImo+aUs2ecNaW81C8TvaZKm5SHpS0T+TkG P/v3UYZHnavxIv9vTgq/BjgeksOWo+8= Received: from localhost.junc.eu (localhost.junc.eu [IPv6:::1]) by mx.junc.eu (Postfix) with ESMTPSA id 184A87FEE0 for ; Tue, 22 Dec 2020 02:37:52 +0000 (UTC) MIME-Version: 1.0 Date: Tue, 22 Dec 2020 03:37:52 +0100 From: Benny Pedersen To: dmarc@ietf.org In-Reply-To: <8c6c4f7f-4a95-cd2b-306e-83a50dcde385@tana.it> References: <1e61f7c4-c6d2-5dab-dfc7-f1fd740e1d0d@tana.it> <20201219194954.BF87E2ADF1FB@ary.qy> <9b7cc1c9-e031-4ef8-8d92-2c16cc4fa073@tana.it> <496c92bc02e75c2d7b02365d9dd0cf38@junc.eu> <8c6c4f7f-4a95-cd2b-306e-83a50dcde385@tana.it> User-Agent: Roundcube Webmail/1.4.8 Message-ID: X-Sender: me@junc.eu Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [dmarc-ietf] ARC vs p=quarantine X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 22 Dec 2020 02:37:57 -0000 On 2020-12-21 18:27, Alessandro Vesely wrote: > On Mon 21/Dec/2020 01:52:11 +0100 Benny Pedersen wrote: >> On 2020-12-20 23:07, Michael Thomas wrote: >>> On 12/20/20 2:01 PM, Benny Pedersen wrote: > For the message I'm replying to, I got: >=20 > Authentication-Results: wmail.tana.it; > spf=3Dpass smtp.mailfrom=3Dietf.org; > dkim=3Dpass reason=3D"Original-From: transformed" (whitelisted)=20 > header.d=3Djunc.eu; > dkim=3Dpass (whitelisted) header.d=3Dietf.org > header.b=3DGUNfiCpP; > dkim=3Dfail (signature verification failed, whitelisted)=20 > header.d=3Dietf.org > header.b=3DIIMQxhd+ >=20 > Two out of three is not bad, is it? If IETF only did ARC seals, I'd > probably verified no signature at all =E2=80=94since I don't run ARC chec= ks. metacpan Mail::DKIM gives dkim invalid if just one dkim is invalid, so=20 spamassassin says aswell dkim invalid what software used above to show this results ? From nobody Tue Dec 22 01:22: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 21C3D3A0EB3 for ; Tue, 22 Dec 2020 01:22:29 -0800 (PST) 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, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 59ySoFO4vYKC for ; Tue, 22 Dec 2020 01:22:27 -0800 (PST) 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 4819F3A0EAF for ; Tue, 22 Dec 2020 01:22:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1608628942; bh=qMVmhshtK6jOcj2zG28jdEmkc9YKmMElpR09jxFDQC0=; l=1692; h=To:References:From:Date:In-Reply-To; b=BC746zjaQCILSRg0xaVf0+MJYd5MoLDteCDivc0xnUzQwgGjunM0sMwjR9SsSQ+yZ 56jIKmS2/eR2UfcPHuFYNRCzwq5kry/FgKP30pjumW4+TgFjATQegqYzK3KBsFE1z3 fKpKbqSVNY6Ui3hBqZlnifFXyXrT8sKVZD42lW/g/kJ2oFvVZT8NZQAUp7gCQ Authentication-Results: tana.it; auth=pass (details omitted) Original-From: Alessandro Vesely 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.000000005FE1BACE.00007BD8; Tue, 22 Dec 2020 10:22:22 +0100 To: John R Levine , dmarc@ietf.org References: <20201218023900.E73B82ACBB2B@ary.qy> <4a43ffaa-3987-c892-cce7-56f18888cdf5@tana.it> <39125012-e356-d62d-36fd-a7ff25a9f59f@taugh.com> <6bba023-d3d9-63a5-8441-11dac9a05e28@taugh.com> <74051a64-871a-db72-b5d9-1be374e23015@tana.it> <3034face-b6fc-0ce2-fa1b-f59210bd6f5b@tana.it> <46339b38-3b24-bcb7-5e73-8a97038ed69@taugh.com> From: Alessandro Vesely Message-ID: <3997c81d-3b30-0823-a752-fb1d60a44593@tana.it> Date: Tue, 22 Dec 2020 10:22:22 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: <46339b38-3b24-bcb7-5e73-8a97038ed69@taugh.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Ticket #55 - Clarify legal and privacy implications of failure reports X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Dec 2020 09:22:29 -0000 On Mon 21/Dec/2020 22:01:44 +0100 John R Levine wrote: >> What is evident is that, as conceived, failure reports break privacy enough >> to make an admin's skin crawl. > > Right. > >> I think we should convey the fact that failure reports are (to be) sent in >> limited circumstances and with due circumspection. > > Yes, that is more or less what I have been saying, only I'd say you probably > don't want to send them at all since they have turned out not to be important. Saying so ourselves would corroborate our credibility. One place to change is the second paragraph in the Introduction. For example: OLD "Failure reports," or "failed message reports," provide diagnostic information about messages that a Mail Receiver has determined do not pass the DMARC mechanism. These reports are generally sent at the time such messages are received and evaluated, to provide the Domain Owner with timely notification that such failures are occurring, and to provide information that may assist in diagnosing the cause of the failures. NEW Failure reports provide detailed information about the failure of a single message or a group of similar messages failing for the same reason. They are meant to aid extreme cases where a domain owner is unable to detect why failures reported in aggregate form did occur. As an extension of other kinds of failure notifications, these reports can contain either the content of a failed message or just its header. The latter characteristic entails severe privacy concerns. For that reason, and because it turned out not to be important, failure reporting is usually disabled. Best Ale -- From nobody Tue Dec 22 01:38: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 031F73A0EC6 for ; Tue, 22 Dec 2020 01:38:09 -0800 (PST) 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, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 c6uLogiOVIDv for ; Tue, 22 Dec 2020 01:38:07 -0800 (PST) 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 854503A0EC4 for ; Tue, 22 Dec 2020 01:38:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1608629885; bh=alQurCb5718SRbJActGq85KGIsRSh1PticYzBUSiq8g=; l=1583; h=To:References:From:Date:In-Reply-To; b=BFHVHGr3bwBNRQsFpTED/7k+JxIR1Hv6qm2lwDySlrYS1ijichQnoikm5lq0rxPzg XENz2BC40gs+Oj6gM21yEPI7ohQDw7YPOjqvwVVJPcgG8Kbsgcw6gQctabkO3ZAQh6 6bqFGp7k1mgeK2seHtf4DisQT7zmv5ZHIxrI9ZUqNoGW3Q6rbHRmIae6lkeWQ Authentication-Results: tana.it; auth=pass (details omitted) Original-From: Alessandro Vesely 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.000000005FE1BE7D.00007D5D; Tue, 22 Dec 2020 10:38:05 +0100 To: dmarc@ietf.org References: <1e61f7c4-c6d2-5dab-dfc7-f1fd740e1d0d@tana.it> <20201219194954.BF87E2ADF1FB@ary.qy> <9b7cc1c9-e031-4ef8-8d92-2c16cc4fa073@tana.it> <496c92bc02e75c2d7b02365d9dd0cf38@junc.eu> <8c6c4f7f-4a95-cd2b-306e-83a50dcde385@tana.it> From: Alessandro Vesely Message-ID: <0c209b30-cb18-c8db-6f2c-9c588c309644@tana.it> Date: Tue, 22 Dec 2020 10:38:05 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] ARC vs p=quarantine X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 22 Dec 2020 09:38:09 -0000 On Tue 22/Dec/2020 03:37:52 +0100 Benny Pedersen wrote: > On 2020-12-21 18:27, Alessandro Vesely wrote: >> On Mon 21/Dec/2020 01:52:11 +0100 Benny Pedersen wrote: > >> For the message I'm replying to, I got: >> >> Authentication-Results: wmail.tana.it; >>   spf=pass smtp.mailfrom=ietf.org; >>   dkim=pass reason="Original-From: transformed" (whitelisted) header.d=junc.eu; >>   dkim=pass (whitelisted) header.d=ietf.org >>     header.b=GUNfiCpP; >>   dkim=fail (signature verification failed, whitelisted) header.d=ietf.org >>     header.b=IIMQxhd+ >> >> Two out of three is not bad, is it?  If IETF only did ARC seals, I'd >> probably verified no signature at all —since I don't run ARC checks. > > metacpan Mail::DKIM gives dkim invalid if just one dkim is invalid, so > spamassassin says aswell dkim invalid I don't think that's a reasonable choice. A DKIM informative note exemplifies this very case: INFORMATIVE NOTE: The rationale of this requirement is to permit messages that have invalid signatures but also a valid signature to work. For example, a mailing list exploder might opt to leave the original submitter signature in place even though the exploder knows that it is modifying the message in some way that will break that signature, and the exploder inserts its own signature. In this case, the message should succeed even in the presence of the known-broken signature. https://tools.ietf.org/html/rfc6376#section-6.1 > what software used above to show this results ? zdkimfilter Best Ale -- From nobody Tue Dec 22 07:42: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 35E253A1117 for ; Tue, 22 Dec 2020 07:42:03 -0800 (PST) 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 vugmNRifa527 for ; Tue, 22 Dec 2020 07:42:01 -0800 (PST) Received: from mail-qt1-x831.google.com (mail-qt1-x831.google.com [IPv6:2607:f8b0:4864:20::831]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3EFD3A1116 for ; Tue, 22 Dec 2020 07:42:00 -0800 (PST) Received: by mail-qt1-x831.google.com with SMTP id b9so9201431qtr.2 for ; Tue, 22 Dec 2020 07:42:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=+n3lbDftU/YhGyLbuFA0dSD8JiE3S9kLw9UE+mIicFk=; b=Q9wMvyZQwv/ijbtERJBDZyR0/S7b5pajZXnoBtTzTwo29EUdHh5vtNP1j605a4i0+l kUAzXtII0/wVYljQvqBskBc4LouON2Jd7bFSKmxwmnX7U5cUfiFybzuVoLCyMUh9lqtg a+eAgZ8HyzOEsaCrhgBJ76VYm+0QK3484mlAUmT7EDypVqasKAorhradP92uQP9KRJZ3 xVXEMlcDRYQSIDGVitL1DB5vu6Mis9OHVfrfRJmO5ljS4jWtY1x2vAFLKjECDas6Q1Dc y7zRgOp99tIPQKGV84caSfrn4UHJbQEzWTvY9r7MkoeNwufAFFslttCRRaGwa8+ZPCT9 gD3w== 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=+n3lbDftU/YhGyLbuFA0dSD8JiE3S9kLw9UE+mIicFk=; b=F/WBHtLnjAv5LkB8NDRQhXzC/C70fvLU4XxRE2K5Pea4MEnKrAeoYJkIgau330QvIC Ji3f2cdDKH9/PFDa5pKz8ApU538iHbh/LMOBn0I+vVCWNVD/+2chVGHfBkQ7CRM7pIOI Os7ykk0tRmy5aYF0DLM6AhmrsEmUSH+7V+lGjZyqfaCDSDReK/4ROAzq5bd6FOAP+uMn ItsXTN6t1iOvbKPdvDVAqfgKoJ4B9FxESAzw2SSd5fgWKSayffcZ117xqgomWO3aznBM sUU+eb3ORu7k6xpz03G/YHFCPkCwtKwwcA+oL4UOQKQS6XRWlFtLfYLhNABJI6XrrQnP KgZg== X-Gm-Message-State: AOAM533Y2xyxTQQ4F5jHVM0KHUWi61c/Nkj1Qx501BlwgpihBo+tYlcH 2bFu4MtzT0NQ1Jrhbc9akGmfcvlFlNlycBF8gnVNvc5YH8s= X-Google-Smtp-Source: ABdhPJwgZZ9GT1Q6U/pekJDb0VusJpOynD266jg4d5rWtZ2tn6wB8whH/3XjlvyC6hW2PQtFbbXgxjdkzBbkwWimMrw= X-Received: by 2002:a05:622a:14e:: with SMTP id v14mr21800986qtw.298.1608651719520; Tue, 22 Dec 2020 07:41:59 -0800 (PST) MIME-Version: 1.0 References: <20201211173722.6B4DF29782C7@ary.qy> <02f786e5-b7cd-9a89-e3e3-73594f3bcda0@mtcc.com> In-Reply-To: From: Todd Herr Date: Tue, 22 Dec 2020 10:41:43 -0500 Message-ID: To: IETF DMARC WG Content-Type: multipart/alternative; boundary="0000000000004f473405b70f6a96" Archived-At: Subject: Re: [dmarc-ietf] p=quarantine X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 22 Dec 2020 15:42:03 -0000 --0000000000004f473405b70f6a96 Content-Type: text/plain; charset="UTF-8" On Mon, Dec 21, 2020 at 12:47 PM Alessandro Vesely wrote: > On Sun 20/Dec/2020 18:10:03 +0100 Todd Herr wrote: > > > > Lists are a specific instance of the more general case of indirect mail > flows. > > > How many kinds of indirect mail flows do rewrite From:? > > Specific methods might prove more effective than general ones. > > Sender Rewriting Scheme (SRS) exists for the rewriting of the RFC5321.From address, and is sometimes used in mail that is forwarded by rule, say from @ alum.institution.edu to @consumerMailboxProvider.com The larger point, though, is that mail that automatically passes through one or more intermediary hosts on its way to its final destination can fail authentication checks at the final destination due to the impact of changes on the message, either in path, or content, or both, as it traverses that journey. It seems to me that we can either work to find a way to ensure that such failures don't happen, or we can work to find a reliable and trustworthy way to record authentication results along the way so that the failures can be mitigated and not result in failed delivery of wanted mail. > > [...] > > > > Since the receiver typically can't perform the same checks under the > same > > conditions that existed when the intermediary performed them (if it > could, we > > wouldn't need something like ARC) then the receiver has to decide if the > > message is consistent with messages it's previously seen through direct > mail > > flows using that same authenticated identity that was captured by the > > intermediary in the ARC header set. > > > Doesn't that assume some kind of omniscience at the receiver's? > Consistency > with previous messages by the same source is not straightforward. Using > the > same selector? Signing more or less the same set of header fields? > Choice of > vocabulary? HTML vs. plain text style (e.g. line length)? A.I.? > > Not omniscience, no, but certainly a method of tracking an authenticated identity's reputation, and consistency of reputation is what I'm speaking of. Allow me to try again to get across the idea that I'm so far failing to make clear. I'm not currently working for a mailbox provider, but I have in the past, and so I will role play as one here. As a mailbox provider, I have a system for authenticating the identity or identities associated with messages that come directly to me. These authenticated identities can include some or all of: - The DKIM signing domain(s) - The DKIM signing domain(s) and selector(s) - The RFC5322.From domain (authenticated using DMARC) - The RFC5321.From domain (SPF) - The IP address of the client that passed the message to me - The domain associated with the PTR record of that IP address - Others as I deem useful For each of these authenticated identities, I can and will track how my users/customers/mailbox holders engage with the mail they receive, thus over time establishing in my system a reputation to associate with each authenticated identity. If, for example, mail that is DKIM signed using selector S and domain D is mail that my users demonstrate through their actions (opening it, clicking on links in it, etc.) is wanted mail, then that authenticated identity (S._domainkey.D) will be associated with a good reputation (however I define "good") in my system. Lather, rinse, and repeat for other authenticated identities associated with the message, and allow that both good and bad reputations can be earned. Now here comes a message that is DKIM-signed by D with selector S, and it fails DKIM validation when I do my checks. However, in scanning the message, I see that there is an ARC header set, one that was signed and sealed by A, and in that ARC header set is an ARC-Authentication-Results header that says that the message passed DKIM validation with signing domain D and selector S when A did its check. My conundrum here is "Do I trust A's claim that the message was correctly DKIM signed by domain D with selector S?" The answer to that question will depend on how my users treat the message and others like it, assuming that I accept it and deliver it. If my users treat such messages in a manner that's consistent with how they treat direct mail flow that is DKIM-signed by D with selector S, then A's reputation as an ARC-sealer/signer will be positive, because A will establish with me a history of being a source of ARC-sealed/signed mail with ARC header sets that can be believed. On the other hand, if my users consistently treat such messages differently than they do direct mail flow that is DKIM-signed by D with selector s, then A's reputation as an ARC-sealer/signer will be negatively impacted with me, because I will not have evidence in hand that this is a path for mail with an authenticated identity of S._domainkey.D to take. The point here is that ARC (or any system designed to capture intermediate authentication results) can only succeed if the downstream recipients of the message trust the information that the intermediary host(s) record in the message. What I'm describing above is one way to determine if that information can be trusted, one that I'm trying to design to scale beyond "Let me just whitelist these X hosts as reliable ARC sealer/signers." -- *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. --0000000000004f473405b70f6a96 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Dec 21, 2020 at 12:47 PM Alessand= ro Vesely <vesely@tana.it> wrot= e:
On Sun 20/Dec/2020 18:10:03 +0100 Todd Herr wrote:
>
> Lists are a specific instance of the more general case of indirect mai= l flows.


How many kinds of indirect mail flows do rewrite From:?

Specific methods might prove more effective than general ones.


Sender Rewriting Scheme (SRS) exists f= or the rewriting of the RFC5321.From address, and is sometimes used in mail= that is forwarded by rule, say from=C2=A0@alum.institution.edu to=C2=A0@consumerMailboxProvider.com
=

The larger point, though, is that mail that automatical= ly passes through one or more intermediary hosts on its way to its final de= stination can fail authentication checks at the final destination due to th= e impact of changes on the message, either in path, or content, or both, as= it traverses that journey. It seems to me that we can either work to find = a way to ensure that such failures don't happen, or we can work to find= a reliable and trustworthy way to record authentication results along the = way so that the failures can be mitigated and not result in failed delivery= of wanted mail.


> [...]
>
> Since the receiver typically can't perform the same checks under t= he same
> conditions that existed when the intermediary performed them (if it co= uld, we
> wouldn't need something like ARC) then the receiver has to decide = if the
> message is consistent with messages it's previously seen through d= irect mail
> flows using that same authenticated identity that was captured by the =
> intermediary in the ARC header set.


Doesn't that assume some kind of omniscience at the receiver's?=C2= =A0 Consistency
with previous messages by the same source is not straightforward.=C2=A0 Usi= ng the
same selector?=C2=A0 Signing more or less the same set of header fields?=C2= =A0 Choice of
vocabulary?=C2=A0 HTML vs. plain text style (e.g. line length)?=C2=A0 A.I.?=


Not omniscience, no, but certainly a m= ethod of tracking an authenticated identity's=C2=A0reputation, and cons= istency of reputation is what I'm speaking of. Allow me to try again to= get across the idea that I'm so far failing to make clear.
<= br>
I'm not currently working for a mailbox provider, but I h= ave in the past, and so I will role play as one here.

<= div>As a mailbox provider, I have a system for authenticating the identity = or identities associated with messages that come directly to me.=C2=A0

These authenticated identities can include some or all= of:
  • The DKIM signing domain(s)
  • The DKIM signing = domain(s) and selector(s)
  • The RFC5322.From domain (authenticated us= ing DMARC)
  • The RFC5321.From domain (SPF)
  • The IP address of = the client that passed the message to me
  • The domain associated with= the PTR record of that IP address
  • Others as I deem useful
    • For each of these authenticated identities, I can and will track how = my users/customers/mailbox holders engage with the mail they receive, thus = over time establishing in my system a reputation to associate with each aut= henticated identity. If, for example, mail that is DKIM signed using select= or S and domain D is mail that my users demonstrate through their actions (= opening it, clicking on links in it, etc.) is wanted mail, then that authen= ticated identity (S._domainkey.D) will be associated with a good reputation= (however I define "good") in my system. Lather, rinse, and repea= t for other authenticated identities associated with the message, and allow= that both good and bad reputations can be earned.

    Now here comes a message that is DKIM-signed by D with selector S, and it = fails DKIM validation when I do my checks. However, in scanning the message= , I see that there is an ARC header set, one that was signed and sealed by = A, and in that ARC header set is an ARC-Authentication-Results header that = says that the message passed DKIM validation with signing domain D and sele= ctor S when A did its check.

My conundrum he= re is "Do I trust A's claim that the message was correctly DKIM si= gned by domain D with selector S?"

The answer= to that question will depend on how my users treat the message and others = like it, assuming that I accept it and deliver it. If my users treat such m= essages in a manner that's consistent with how they treat direct mail f= low that is DKIM-signed by D with selector S, then A's reputation as an= ARC-sealer/signer will be positive, because A will establish with me a his= tory of being a source of ARC-sealed/signed mail with ARC header sets that = can be believed. On the other hand, if my users consistently treat such mes= sages differently than they do direct mail flow that is DKIM-signed by D wi= th selector s, then A's reputation as an ARC-sealer/signer will be nega= tively impacted with me, because I will not have evidence in hand that this= is a path for mail with an authenticated identity of S._domainkey.D to tak= e.

The point here is that ARC (or any system desig= ned to capture intermediate authentication results) can only succeed if the= downstream recipients of the message trust the information that the interm= ediary host(s) record in the message. What I'm describing above is one = way to determine if that information can be trusted, one that I'm tryin= g to design to scale beyond "Let me just whitelist these X hosts as re= liable ARC sealer/signers."

--

Todd Herr | Sr. Tec= hnical Program Manager
= p: 703.220.4153
=


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

--0000000000004f473405b70f6a96-- From nobody Tue Dec 22 08:05: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 A237A3A113C for ; Tue, 22 Dec 2020 08:05:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, 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=mtcc.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 pfEOPtmvEnOx for ; Tue, 22 Dec 2020 08:05:45 -0800 (PST) Received: from mail-pg1-x52e.google.com (mail-pg1-x52e.google.com [IPv6:2607:f8b0:4864:20::52e]) (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 2C10F3A1139 for ; Tue, 22 Dec 2020 08:05:44 -0800 (PST) Received: by mail-pg1-x52e.google.com with SMTP id p18so8628125pgm.11 for ; Tue, 22 Dec 2020 08:05:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mtcc.com; s=fluffulence; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=J7e8qD0NI2Nrzd0B5yoIKei4DOHwGiJaO3JTpDBtACA=; b=O5Rp/mSiyEI2KvF84oZfUQWdO32n4A0x5fgOlqb11ESdExg3z7gMUUdTkpIfDvLYM2 bO7Bgzi3CDlGExUDOcK99NpapUCxHJoZ3QndG8mXb5jNhxTefcjA828ZNFlilA8PGlCH I+3VHkkaBkgQkmmlIx65zaMCUC8SDhVNeLCUPeZrfIQ35eX40APQS642Tm81RQnllf2o b5MwPEHtmhAGmnd0UekDbtcnxLPh0IiWJsxQLh5ocQhWdXFPKNaWAFMsVL/qX2znQOTc BPSMMatwR1hrsUf2vcUiufNPkCN5h8QTfRoAyJtkXfjBq639aPe4LFvIIDl3kx/BNeNs mVVQ== 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=J7e8qD0NI2Nrzd0B5yoIKei4DOHwGiJaO3JTpDBtACA=; b=j5ManaKBVyxPl4O0reB3VKlvNYY17LypTz7a5jLERoRpXNKLUi7alp/G2slE4LTdvB SY2TegPC1zvTLY8usR7wiHd/mxybgXl1eVVe//odeycXZeqIhw6o5pmeQ+UAYnhIHCz/ TGPg0FX3unu3anrtXg1qOBR9GTb++6qzhcnU9f30Ps+Ixa6pOCOnLCBMjKM2Enx0KLJU q26XxA9g+qJbEWbEecbGB1FC3aRNgKYKcDbkNoFRHu+ZOo0N9r6/xQwquNnK3z1wZNmG cYYIgJd6zjxHsTg9F004IlSq2wTm8PK2K+IHOVjiBYjNaAmVLz2nVl0YZi4bglugYCws 0xeg== X-Gm-Message-State: AOAM530/9gG0mi7zbz6MmZ0JbjfvXg3dR1Zd/j4cnlgqmk2D0/h5ycfY XydM5h8FbqgOlWM24lWxvddyNNSNpCAw5A== X-Google-Smtp-Source: ABdhPJzS+O7lmbcJGIthuZWB3RdtrM3Lr3nIAjw1W1iWQyyucFwcUe936aQshxoSIZyYZBnJ6cKZAw== X-Received: by 2002:a62:1ad0:0:b029:197:e389:fb26 with SMTP id a199-20020a621ad00000b0290197e389fb26mr20479520pfa.20.1608653143937; Tue, 22 Dec 2020 08:05:43 -0800 (PST) Received: from mike-mac.lan ([107.182.37.0]) by smtp.gmail.com with ESMTPSA id z11sm21361413pfj.191.2020.12.22.08.05.42 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 22 Dec 2020 08:05:43 -0800 (PST) To: dmarc@ietf.org References: <20201211173722.6B4DF29782C7@ary.qy> <02f786e5-b7cd-9a89-e3e3-73594f3bcda0@mtcc.com> From: Michael Thomas Message-ID: Date: Tue, 22 Dec 2020 08:05:41 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------3D827BE84E453F3225D3CB15" Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] p=quarantine X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 22 Dec 2020 16:05:50 -0000 This is a multi-part message in MIME format. --------------3D827BE84E453F3225D3CB15 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 12/22/20 7:41 AM, Todd Herr wrote: > > My conundrum here is "Do I trust A's claim that the message was > correctly DKIM signed by domain D with selector S?" > which is why ARC brings nothing new to the table. it's not that it was correctly signed by the originator, it's whether i trust the mangler at all. if i do, then i implicitly trust that they handled the dkim verification too. it would be a lot more productive to work on that trust problem than hoping a renamed dkim signature is going to somehow change that. Mike --------------3D827BE84E453F3225D3CB15 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit


On 12/22/20 7:41 AM, Todd Herr wrote:

My conundrum here is "Do I trust A's claim that the message was correctly DKIM signed by domain D with selector S?"

which is why ARC brings nothing new to the table. it's not that it was correctly signed by the originator, it's whether i trust the mangler at all. if i do, then i implicitly trust that they handled the dkim verification too. it would be a lot more productive to work on that trust problem than hoping a renamed dkim signature is going to somehow change that.

Mike

--------------3D827BE84E453F3225D3CB15-- From nobody Tue Dec 22 08:16: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 ED5863A1146 for ; Tue, 22 Dec 2020 08:16:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, 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=mtcc.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 5SwGLf06f-Yu for ; Tue, 22 Dec 2020 08:16:09 -0800 (PST) Received: from mail-pg1-x533.google.com (mail-pg1-x533.google.com [IPv6:2607:f8b0:4864:20::533]) (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 EED343A1145 for ; Tue, 22 Dec 2020 08:16:08 -0800 (PST) Received: by mail-pg1-x533.google.com with SMTP id f17so8653362pge.6 for ; Tue, 22 Dec 2020 08:16:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mtcc.com; s=fluffulence; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=va7hEoDeThNTK+UynkJ4hmkx4AgN+XIalyaCqz1D+Lk=; b=ZeMqpZheGosiQFVLfH/HPqKqA6f2q95DMJOvLfr2OXUwsgv1IWuhU0YZ30CktSjANO 78ZXKjwMR2hBc+r0V3eiFRaU/Yi0Jva9/E8pOQqmoSXM+L6nCwqxOswLR1BXuUSbxLOl 9aftxPA399EumHZMQoUhUcnqZp9ZVw4OulGhObF6tGZzEpZAgkkQf3Q0Y+YO/wXBVHNE I+feWZ7nrvipy+Nkpq4P+o25npQluCmM+TxyRd9mX0nV6Wj4mtUOPluOCxwzRMDzCxOi sFK2xV7ndHB8MI88LYviK5ylRbI/qQUA8sMMULJgH9zhiAowmdjOO4w1zCG7GrE13cuC 8ofQ== 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=va7hEoDeThNTK+UynkJ4hmkx4AgN+XIalyaCqz1D+Lk=; b=Oabvk/gz/qT79lvAYvBaNoyoCXu3nskL8kj8Wnxve2RMJaUVCSckcl6/k1pRNfrot8 L3QFK2exdtRvQ4MEm6oGKLt5cQyzVyx8EnrKvtqQbX7Fwre80ThZpEY+WIIAa+3fmuOg Z3M5KpxV5mAqPBXnOI7r/BXLjqEQjdQjMWZ+DiwYnFsqeak52/vrbLXnrPA6csWu7qVk ZAD0Sc8S7bIYhOw50HSAEOfDnVKJjhc7G1RuCzSaIT53as/YCC4agKNTyjmNi+2/BQL6 pV4nCDvdh1FledeuNWEKbp9d8AoGqwGhuaGvx+0qqUR5p5fAKX9+FoVB4K8NJWRJsl31 sSpA== X-Gm-Message-State: AOAM530F1YJmAmnXsf2PqwXtD/wEGKr6Rj6xZ0VP9OMEJGBjgPXM5XRo i+3vgY5SqXKzwf4IfaXweUY+gcdO0o6lWQ== X-Google-Smtp-Source: ABdhPJza8MYv258NYBw+JBEL1mj6MUD7+Z3FpbsWn9vtvxGFULTjmWo9BjdkWVGgiRuTGMy41nqxqg== X-Received: by 2002:a65:460d:: with SMTP id v13mr17820572pgq.414.1608653767838; Tue, 22 Dec 2020 08:16:07 -0800 (PST) Received: from mike-mac.lan ([107.182.37.0]) by smtp.gmail.com with ESMTPSA id y27sm21318999pfr.78.2020.12.22.08.16.06 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 22 Dec 2020 08:16:07 -0800 (PST) To: dmarc@ietf.org References: <20201218023900.E73B82ACBB2B@ary.qy> <4a43ffaa-3987-c892-cce7-56f18888cdf5@tana.it> <39125012-e356-d62d-36fd-a7ff25a9f59f@taugh.com> <6bba023-d3d9-63a5-8441-11dac9a05e28@taugh.com> <74051a64-871a-db72-b5d9-1be374e23015@tana.it> <3034face-b6fc-0ce2-fa1b-f59210bd6f5b@tana.it> <46339b38-3b24-bcb7-5e73-8a97038ed69@taugh.com> <3997c81d-3b30-0823-a752-fb1d60a44593@tana.it> From: Michael Thomas Message-ID: <448eeae1-2d82-91d3-4adf-cb547acd427a@mtcc.com> Date: Tue, 22 Dec 2020 08:16:05 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 MIME-Version: 1.0 In-Reply-To: <3997c81d-3b30-0823-a752-fb1d60a44593@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] Ticket #55 - Clarify legal and privacy implications of failure reports X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Dec 2020 16:16:10 -0000 On 12/22/20 1:22 AM, Alessandro Vesely wrote: > > NEW > >    Failure reports provide detailed information about the failure of a > single >    message or a group of similar messages failing for the same > reason.  They >    are meant to aid extreme cases where a domain owner is unable to > detect why >    failures reported in aggregate form did occur.  As an extension of > other >    kinds of failure notifications, these reports can contain either > the content >    of a failed message or just its header.  The latter characteristic > entails >    severe privacy concerns.  For that reason, and because it turned > out not to >    be important, failure reporting is usually disabled. > I'm not understanding what this "severe privacy concerns" are. It looks like a glorified bounce message to me. My messages pass through the originating domain in the clear, but it only becomes a "severe privacy concern" when it is reflected back? How does that work? Mike From nobody Tue Dec 22 08:39: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 10F103A1167 for ; Tue, 22 Dec 2020 08:39:14 -0800 (PST) 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 (2048-bit key) header.d=iecc.com header.b=WC5Hr9lJ; dkim=pass (2048-bit key) header.d=taugh.com header.b=cAuXY0E6 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jWEFVypariBx for ; Tue, 22 Dec 2020 08:39:12 -0800 (PST) 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 DE2083A1166 for ; Tue, 22 Dec 2020 08:39:11 -0800 (PST) Received: (qmail 14453 invoked from network); 22 Dec 2020 16:39:10 -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=3872.5fe2212e.k2012; i=johnl-iecc.com@submit.iecc.com; bh=LZ5abR+XRwrST2izVO7dF7P1Rj3BWXfG9i4HNPmrv3k=; b=WC5Hr9lJHJAerfrIsEqHFDPkT/LV2WIzN52dtVvlaet7br9HtzRPjNcxDbdS6LXrKDi7uaq2BThaV3YP2u/0A4TjOOE2LSt63zxqa2AVdyT/WUS7RurFJGw42gYwGmiY71UvbKrIkTREZBY/7HQ6no8vqUMtVfH81L1ofPrypNPJhPs6BDHxmdnJMnF0S0x6lW7W4RDNqiPaq/JGi4X3wZ1ua7kRg0HsX8792zWqMev3SmTAwWqIK06gcyY8bVW+kNMB9rNfK064keI6xBQAt1o5zQ783M8VJt5wEiqaSPwi1jtU9o10u53vV3lP7Qr8/jghw5uVu6vwDVlB4eJd1Q== 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=3872.5fe2212e.k2012; olt=johnl-iecc.com@submit.iecc.com; bh=LZ5abR+XRwrST2izVO7dF7P1Rj3BWXfG9i4HNPmrv3k=; b=cAuXY0E6OHn2LLzWB52MZq5L7j7OYuH5OE0PIUVBSkEBcVeB1yqEM1MGFi0vc8zwGG5bZry75R4x4WnciLEYcjHVkISRSLsJZkWHjYprMw3WRAyHdt8I2PRVV/plHjhgjC7OPQDk/UAbbjCKAVkZa0Qe28Lyb0ilSSmv21OoyQxgFE1jZz28Q3S7Vzyq+9J4YUt2PTz1r9BLeFqiYEkgJQ/f1oHC+7Px6UgKfft6GAivoiOK370q5YrfUHpKZp0IWBqu4DmE9K+W7UzdEOrRnclKK0kEXXewqpusFX1KVQwYaj6KyuJgp7CUbzLxqv8tN81DQtfRAXHaV5j8m79d/w== 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; 22 Dec 2020 16:39:09 -0000 Date: 22 Dec 2020 11:39:09 -0500 Message-ID: <74a5c37-19a6-6f6f-a51d-6e5cca5b29e8@taugh.com> From: "John R Levine" To: "Alessandro Vesely" , dmarc@ietf.org In-Reply-To: <3997c81d-3b30-0823-a752-fb1d60a44593@tana.it> References: <20201218023900.E73B82ACBB2B@ary.qy> <4a43ffaa-3987-c892-cce7-56f18888cdf5@tana.it> <39125012-e356-d62d-36fd-a7ff25a9f59f@taugh.com> <6bba023-d3d9-63a5-8441-11dac9a05e28@taugh.com> <74051a64-871a-db72-b5d9-1be374e23015@tana.it> <3034face-b6fc-0ce2-fa1b-f59210bd6f5b@tana.it> <46339b38-3b24-bcb7-5e73-8a97038ed69@taugh.com> <3997c81d-3b30-0823-a752-fb1d60a44593@tana.it> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [dmarc-ietf] Ticket #55 - Clarify legal and privacy implications of failure reports X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Dec 2020 16:39:14 -0000 I think that text is way too long and overspecific but we've already spent too much time on this so I'll stop and see if there are other opinions. On Tue, 22 Dec 2020, Alessandro Vesely wrote: > OLD > > "Failure reports," or "failed message reports," provide diagnostic > information about messages that a Mail Receiver has determined do not > pass the DMARC mechanism. These reports are generally sent at the > time such messages are received and evaluated, to provide the Domain > Owner with timely notification that such failures are occurring, and > to provide information that may assist in diagnosing the cause of the > failures. > > > NEW > > Failure reports provide detailed information about the failure of a single > message or a group of similar messages failing for the same reason. They > are meant to aid extreme cases where a domain owner is unable to detect > why > failures reported in aggregate form did occur. As an extension of other > kinds of failure notifications, these reports can contain either the > content > of a failed message or just its header. The latter characteristic entails > severe privacy concerns. For that reason, and because it turned out not > to > be important, failure reporting is usually disabled. 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 Dec 22 08: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 1B9BA3A117C for ; Tue, 22 Dec 2020 08:51:07 -0800 (PST) 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, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 3Z4iLNw3oSZs for ; Tue, 22 Dec 2020 08:51:03 -0800 (PST) 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 2EA523A117B for ; Tue, 22 Dec 2020 08:51:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1608655859; bh=qqdI4j4lPot+XYN0+wEEjkYRdTS0qud5VAjzMilFZho=; l=1746; h=To:References:From:Date:In-Reply-To; b=CstXm9hQP1fMuKnD2Lwm2faXTs/Mv2Xa+XIpKr8LBNmh1nFUhbVbaw7tsPPLpenXs XuiJG8VzcHuRlAROMR+DKl+28Q1/ecyj2s8EoyFcUqx0NOhJPhLSOhOTE+ei8ICc5/ QKTn9oay6k1vkezd2UgO/FblIqEG5LUdRqMioolGPkEmyvgFKbB8yNa/izTH2 Authentication-Results: tana.it; auth=pass (details omitted) Original-From: Alessandro Vesely 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 00000000005DC07E.000000005FE223F2.000034EB; Tue, 22 Dec 2020 17:50:58 +0100 To: dmarc@ietf.org References: <20201218023900.E73B82ACBB2B@ary.qy> <4a43ffaa-3987-c892-cce7-56f18888cdf5@tana.it> <39125012-e356-d62d-36fd-a7ff25a9f59f@taugh.com> <6bba023-d3d9-63a5-8441-11dac9a05e28@taugh.com> <74051a64-871a-db72-b5d9-1be374e23015@tana.it> <3034face-b6fc-0ce2-fa1b-f59210bd6f5b@tana.it> <46339b38-3b24-bcb7-5e73-8a97038ed69@taugh.com> <3997c81d-3b30-0823-a752-fb1d60a44593@tana.it> <448eeae1-2d82-91d3-4adf-cb547acd427a@mtcc.com> From: Alessandro Vesely Message-ID: Date: Tue, 22 Dec 2020 17:50:58 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: <448eeae1-2d82-91d3-4adf-cb547acd427a@mtcc.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] Ticket #55 - Clarify legal and privacy implications of failure reports X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Dec 2020 16:51:07 -0000 On Tue 22/Dec/2020 17:16:05 +0100 Michael Thomas wrote: > On 12/22/20 1:22 AM, Alessandro Vesely wrote: >> >> NEW >> >>    Failure reports provide detailed information about the failure of a single >>    message or a group of similar messages failing for the same reason.  They >>    are meant to aid extreme cases where a domain owner is unable to detect why >>    failures reported in aggregate form did occur.  As an extension of other >>    kinds of failure notifications, these reports can contain either the content >>    of a failed message or just its header.  The latter characteristic entails >>    severe privacy concerns.  For that reason, and because it turned out not to >>    be important, failure reporting is usually disabled. >> > I'm not understanding what this "severe privacy concerns" are. It looks like a > glorified bounce message to me. My messages pass through the originating domain > in the clear, but it only becomes a "severe privacy concern" when it is > reflected back? How does that work? Unlike bounces, you're delivering PII info to a third party. In Europe, if you setup failure reporting that way, having a third-party handling/ processing meta-data or even mail content requires you to inform your customers about that, and ask permission. If third-party is outside EU, since privacy shield got canceled last July, there is not even a legal basis anymore that would allow you to do so at all. In all cases, you would be held responsible for your customers data unless third-party is signing contracts with you to accept EU privacy laws. EU has severe penalty for companies which breaking GDPR. I cannot tell for Canada or Australia. Best Ale -- From nobody Tue Dec 22 09:02: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 58C1C3A1187 for ; Tue, 22 Dec 2020 09:02:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, 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=mtcc.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 qBtKrMXYBqUi for ; Tue, 22 Dec 2020 09:02:13 -0800 (PST) Received: from mail-pl1-x634.google.com (mail-pl1-x634.google.com [IPv6:2607:f8b0:4864:20::634]) (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 C40893A1183 for ; Tue, 22 Dec 2020 09:02:13 -0800 (PST) Received: by mail-pl1-x634.google.com with SMTP id g3so7741369plp.2 for ; Tue, 22 Dec 2020 09:02:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mtcc.com; s=fluffulence; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=eGvWmUo2VWDDH7IAP0DO5dvorTjxW14lznAm2V+zBbw=; b=hRn6tbtnTvNFvfpsNv1zhsQPt0CTHem9WPT+MpxpTYhwk98mOJsQIMJRTDwLcMOkmG B6hR6QtfTTjDRN50F6ORUV1WHgjaeHhBqpGmZxOSfDoUoFvTKsTL9C38Oj0tLXuyy+Wc 80DcA00wbw078luWKI0tYVEta1JUVBr/cB27nU+m9CpFQl1o5nJx9pkDhRV8608j6cxB 9ePvCzAtmk7qqAqLLum6uGKR5WVnA1Lq8HzDaq3GfT1VJ1aJzWSZR2hmW7nArqI7vjXG 16R9mo16zz+RyC9+yFIpBFfOY1AICe+Kps7Ew5qtH41TPz8HZcO6pAEqG8HlDvGBIrXT 2AoQ== 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=eGvWmUo2VWDDH7IAP0DO5dvorTjxW14lznAm2V+zBbw=; b=b0Wb/dQFy7kkdMuA4v/XOCTaKvoCekEqZKwvVCBMnj2EGyK7kcmsG2+ogyWBk9faMY F+nWcvR/UOLNeNWTojku1OsJhUMxEl5GL9o9Su4JEr0ChDYwBWt55pIGJOgUUkhnN+Cj P30QqqeXES69R37wqFqt1wkeYQ1X7EZmLbV9l19u/XNV0QGV0yEtGRei4Ci4/8A36iSv cKURUiNYJ1COPHfeO4F1dGVCvIRTpVNVF7qw4PoiJhCdX5Es4ZRj745ArONqdgB2Rxq6 BTHlp46zZKDjD093mB1Ih/1BrzasWRHQ/NBDVOg7mVZ73xpuEHA+AWgCrzUBf2ewP7E8 DRrg== X-Gm-Message-State: AOAM531WCerIwtjV2ioxUPDuhLE5wqgzYletGDxzkTbMsuP+ctGmkXak Zyh/WE36qu4Ro6UdBRuHVihO17zs/E6lDA== X-Google-Smtp-Source: ABdhPJwwpdNT1IEeWglopWt6Fi2WV+xukL1KfD568DXY92jlul6EtV+E/26RfleLh1MIXgEbyxXoDw== X-Received: by 2002:a17:90a:df12:: with SMTP id gp18mr22764855pjb.43.1608656532655; Tue, 22 Dec 2020 09:02:12 -0800 (PST) Received: from mike-mac.lan ([107.182.37.0]) by smtp.gmail.com with ESMTPSA id y69sm20813017pfb.64.2020.12.22.09.02.11 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 22 Dec 2020 09:02:11 -0800 (PST) To: dmarc@ietf.org References: <20201218023900.E73B82ACBB2B@ary.qy> <4a43ffaa-3987-c892-cce7-56f18888cdf5@tana.it> <39125012-e356-d62d-36fd-a7ff25a9f59f@taugh.com> <6bba023-d3d9-63a5-8441-11dac9a05e28@taugh.com> <74051a64-871a-db72-b5d9-1be374e23015@tana.it> <3034face-b6fc-0ce2-fa1b-f59210bd6f5b@tana.it> <46339b38-3b24-bcb7-5e73-8a97038ed69@taugh.com> <3997c81d-3b30-0823-a752-fb1d60a44593@tana.it> <448eeae1-2d82-91d3-4adf-cb547acd427a@mtcc.com> From: Michael Thomas Message-ID: <0bf9fb2e-9974-4db3-3165-78508de3547c@mtcc.com> Date: Tue, 22 Dec 2020 09:02:10 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.5.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] Ticket #55 - Clarify legal and privacy implications of failure reports X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Dec 2020 17:02:15 -0000 On 12/22/20 8:50 AM, Alessandro Vesely wrote: > On Tue 22/Dec/2020 17:16:05 +0100 Michael Thomas wrote: >> On 12/22/20 1:22 AM, Alessandro Vesely wrote: >>> >>> NEW >>> >>>    Failure reports provide detailed information about the failure of >>> a single >>>    message or a group of similar messages failing for the same >>> reason.  They >>>    are meant to aid extreme cases where a domain owner is unable to >>> detect why >>>    failures reported in aggregate form did occur.  As an extension >>> of other >>>    kinds of failure notifications, these reports can contain either >>> the content >>>    of a failed message or just its header.  The latter >>> characteristic entails >>>    severe privacy concerns.  For that reason, and because it turned >>> out not to >>>    be important, failure reporting is usually disabled. >>> >> I'm not understanding what this "severe privacy concerns" are. It >> looks like a glorified bounce message to me. My messages pass through >> the originating domain in the clear, but it only becomes a "severe >> privacy concern" when it is reflected back? How does that work? > > > Unlike bounces, you're delivering PII info to a third party. > > In Europe, if you setup failure reporting that way, having a > third-party handling/ processing meta-data or even mail content > requires you to inform your customers about that, and ask permission.  > If third-party is outside EU, since privacy shield got canceled last > July, there is not even a legal basis anymore that would allow you to > do so at all.  In all cases, you would be held responsible for your > customers data unless third-party is signing contracts with you to > accept EU privacy laws.  EU has severe penalty for companies which > breaking GDPR. > > Sorry, having to ask for permission because of laws does not constitute a "severe privacy concern". That is completely outside of the scope of IETF and we should be pandering to it. Mike From nobody Tue Dec 22 10:46: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 9C4293A11FB for ; Tue, 22 Dec 2020 10:46:34 -0800 (PST) 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, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URI_HEX=0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 CChft5FVXCyi for ; Tue, 22 Dec 2020 10:46:31 -0800 (PST) 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 7B81D3A11F9 for ; Tue, 22 Dec 2020 10:46:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1608662789; bh=/EjDx4n1UFKPZsXtxbYvjDrdBWfpGEvJ8ZUL49rJE9U=; l=7456; h=To:References:From:Date:In-Reply-To; b=BQSKvQOfcM6pT0Hj+LBfiTr0yn0FRXy7FMvRGEDnKM/Oyjdtgs7DkO9zdNLyAEq4v QrUnHK/XKVqHNwj+f2Hc9JL1z1TXIizz78L4KONNPGShEipWDPqKpWdVXYRjxiZafN 44FKD1HnjRdZVMf001cx62ZeVgxOgl9yN0g2tohLJB5yTee69MnxiwAdHDKQZ Authentication-Results: tana.it; auth=pass (details omitted) Original-From: Alessandro Vesely 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.000000005FE23F05.000040BC; Tue, 22 Dec 2020 19:46:29 +0100 To: dmarc@ietf.org References: <20201211173722.6B4DF29782C7@ary.qy> <02f786e5-b7cd-9a89-e3e3-73594f3bcda0@mtcc.com> From: Alessandro Vesely Message-ID: Date: Tue, 22 Dec 2020 19:46:29 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] p=quarantine X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 22 Dec 2020 18:46:35 -0000 On Tue 22/Dec/2020 16:41:43 +0100 Todd Herr wrote: > On Mon, Dec 21, 2020 at 12:47 PM Alessandro Vesely wrote: >> On Sun 20/Dec/2020 18:10:03 +0100 Todd Herr wrote: >>> >>> Lists are a specific instance of the more general case of indirect mail >>> flows. >> >> How many kinds of indirect mail flows do rewrite From:? >> >> Specific methods might prove more effective than general ones. > > Sender Rewriting Scheme (SRS) exists for the rewriting of the RFC5321.From > address, and is sometimes used in mail that is forwarded by rule, say from > @alum.institution.edu to @consumerMailboxProvider.com VERP as done by MLMs is more specific (and better thought) than generic SRS. I don't have numbers but off the top of my head I'd reckon MLMs cover a major part of RFC5321.From rewriters. If you additionally select by RFC5322.From rewriting, I'd guess you're left with exactly MLMs. > It seems to me that we can either work to find a way to ensure that > [forwarding] failures don't happen, or we can work to find a reliable and > trustworthy way to record authentication results along the way so that the > failures can be mitigated and not result in failed delivery of wanted mail. Actually, people seem to be doing both. Avoiding gratuitous autoconversions, anti-virus results as footers, and the like, have become a must for most modern MTA software. And there are several mailing lists which operate that way as well. OTOH, modifications are sometimes unavoidable and we still need to cope. >>> Since the receiver typically can't perform the same checks under the >>> same conditions that existed when the intermediary performed them (if it >>> could, we wouldn't need something like ARC) then the receiver has to >>> decide if the message is consistent with messages it's previously seen >>> through direct mail flows using that same authenticated identity that >>> was captured by the intermediary in the ARC header set. >> >> Doesn't that assume some kind of omniscience at the receiver's? >> Consistency with previous messages by the same source is not >> straightforward. Using the same selector? Signing more or less the same >> set of header fields? Choice of vocabulary? HTML vs. plain text style >> (e.g. line length)? A.I.? > > Not omniscience, no, but certainly a method of tracking an authenticated > identity's reputation, and consistency of reputation is what I'm speaking > of. Allow me to try again to get across the idea that I'm so far failing to > make clear. > > I'm not currently working for a mailbox provider, but I have in the past, > and so I will role play as one here. > > As a mailbox provider, I have a system for authenticating the identity or > identities associated with messages that come directly to me. > > These authenticated identities can include some or all of: > > - The DKIM signing domain(s) > - The DKIM signing domain(s) and selector(s) > - The RFC5322.From domain (authenticated using DMARC) > - The RFC5321.From domain (SPF) > - The IP address of the client that passed the message to me > - The domain associated with the PTR record of that IP address > - Others as I deem useful Except for PTR records, that's the data I collect to send out aggregate reports. > For each of these authenticated identities, I can and will track how my > users/customers/mailbox holders engage with the mail they receive, thus > over time establishing in my system a reputation to associate with each > authenticated identity. If, for example, mail that is DKIM signed using > selector S and domain D is mail that my users demonstrate through their > actions (opening it, clicking on links in it, etc.) is wanted mail, then > that authenticated identity (S._domainkey.D) will be associated with a good > reputation (however I define "good") in my system. Lather, rinse, and > repeat for other authenticated identities associated with the message, and > allow that both good and bad reputations can be earned. That's a delicate job. For one point, 20161025._domainkey.gmail.com is not the kind of identifier you want to associate with users' liking, as it is shared among so many messages with diverging characteristics. For another point, there are domains that change selector very often (taugh.com changes it on every message), so it can identify too narrow a message set. Characterizing by author (a.k.a. RFC5322.From) probably works better. An author authenticated by her submission server (a.k.a. author's domain) looks like a good identifier. You still have to sort out authors having multiple email address and using them interchangeably. However, as forwarding of modified messages settles on From: rewriting, recovering that identifier becomes fuzzy. ARC does not cover that bit. If we want to reliably use the author as an identifier, we need those forwarders who rewrite the From: header field —let's call'em MLMs— to adopt a standard way to convey the original value. In my mlm-transform draft, I propose Original-From:. IETF uses X-Original-From:. Mailman uses Reply-To: or Cc:. > Now here comes a message that is DKIM-signed by D with selector S, and it > fails DKIM validation when I do my checks. However, in scanning the > message, I see that there is an ARC header set, one that was signed and > sealed by A, and in that ARC header set is an ARC-Authentication-Results > header that says that the message passed DKIM validation with signing > domain D and selector S when A did its check. > > My conundrum here is "Do I trust A's claim that the message was correctly > DKIM signed by domain D with selector S?" > > The answer to that question will depend on how my users treat the message > and others like it, assuming that I accept it and deliver it. If my users > treat such messages in a manner that's consistent with how they treat > direct mail flow that is DKIM-signed by D with selector S, then A's > reputation as an ARC-sealer/signer will be positive, because A will > establish with me a history of being a source of ARC-sealed/signed mail > with ARC header sets that can be believed. On the other hand, if my users > consistently treat such messages differently than they do direct mail flow > that is DKIM-signed by D with selector s, then A's reputation as an > ARC-sealer/signer will be negatively impacted with me, because I will not > have evidence in hand that this is a path for mail with an authenticated > identity of S._domainkey.D to take. Here you're pairing a method which is fuzzy in nature with one, digital signatures, designed to be strictly binary. You need a very large user base to achieve meaningful results. Most medium/ small mailbox provider, think company servers to family MXes, will not even want to spy on users to determine their liking. > The point here is that ARC (or any system designed to capture intermediate > authentication results) can only succeed if the downstream recipients of > the message trust the information that the intermediary host(s) record in > the message. What I'm describing above is one way to determine if that > information can be trusted, one that I'm trying to design to scale beyond > "Let me just whitelist these X hosts as reliable ARC sealer/signers." Overall, your plan confirms that ARC better suits global mailbox providers. Best Ale -- From nobody Tue Dec 22 11:00: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 B40963A120B for ; Tue, 22 Dec 2020 11:00:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.078 X-Spam-Level: X-Spam-Status: No, score=-2.078 tagged_above=-999 required=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.001, RCVD_IN_MSPIKE_WL=0.001, T_SPF_HELO_TEMPERROR=0.01, T_SPF_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1152-bit key) header.d=tana.it Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dai-dFgtHflf for ; Tue, 22 Dec 2020 11:00:01 -0800 (PST) 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 17BAC3A0688 for ; Tue, 22 Dec 2020 11:00:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1608663598; bh=kUr29PqKmReUITsvIT/QbnQ4BMHnBSa9wB4OU3VV2KE=; l=2244; h=To:References:From:Date:In-Reply-To; b=DZylun8mKFIZUOGJSXoZVd31rfwNJ67bqmt0r2AmeN16BlvYWaGwB0gUnV0dj3s9d MDTUbDiuhvd+fmKNB0BQll31iotDXhpg3qOGTydAuaeLcQ+4f5OtBGX4MTKocDBSOZ w8EzUbMCHFNutDHNMh3Rw/+0HAirJdQNS3FH/NSifmBjVxaST8tSdrFZaCecR Authentication-Results: tana.it; auth=pass (details omitted) Original-From: Alessandro Vesely 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.000000005FE2422E.0000422E; Tue, 22 Dec 2020 19:59:58 +0100 To: dmarc@ietf.org References: <20201218023900.E73B82ACBB2B@ary.qy> <4a43ffaa-3987-c892-cce7-56f18888cdf5@tana.it> <39125012-e356-d62d-36fd-a7ff25a9f59f@taugh.com> <6bba023-d3d9-63a5-8441-11dac9a05e28@taugh.com> <74051a64-871a-db72-b5d9-1be374e23015@tana.it> <3034face-b6fc-0ce2-fa1b-f59210bd6f5b@tana.it> <46339b38-3b24-bcb7-5e73-8a97038ed69@taugh.com> <3997c81d-3b30-0823-a752-fb1d60a44593@tana.it> <448eeae1-2d82-91d3-4adf-cb547acd427a@mtcc.com> <0bf9fb2e-9974-4db3-3165-78508de3547c@mtcc.com> From: Alessandro Vesely Message-ID: <44d92626-a13c-64e7-b1de-07cd50b1fd20@tana.it> Date: Tue, 22 Dec 2020 19:59:58 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: <0bf9fb2e-9974-4db3-3165-78508de3547c@mtcc.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] Ticket #55 - Clarify legal and privacy implications of failure reports X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Dec 2020 19:00:10 -0000 On Tue 22/Dec/2020 18:02:10 +0100 Michael Thomas wrote: > On 12/22/20 8:50 AM, Alessandro Vesely wrote: >> On Tue 22/Dec/2020 17:16:05 +0100 Michael Thomas wrote: >>> On 12/22/20 1:22 AM, Alessandro Vesely wrote: >>>> >>>> NEW >>>> >>>>    Failure reports provide detailed information about the failure of a single >>>>    message or a group of similar messages failing for the same reason.  They >>>>    are meant to aid extreme cases where a domain owner is unable to detect why >>>>    failures reported in aggregate form did occur.  As an extension of other >>>>    kinds of failure notifications, these reports can contain either the content >>>>    of a failed message or just its header.  The latter characteristic entails >>>>    severe privacy concerns.  For that reason, and because it turned out not to >>>>    be important, failure reporting is usually disabled. >>>> >>> I'm not understanding what this "severe privacy concerns" are. It looks like >>> a glorified bounce message to me. My messages pass through the originating >>> domain in the clear, but it only becomes a "severe privacy concern" when it >>> is reflected back? How does that work? >> >> Unlike bounces, you're delivering PII info to a third party. >> >> In Europe, if you setup failure reporting that way, having a third-party >> handling/ processing meta-data or even mail content requires you to inform >> your customers about that, and ask permission. If third-party is outside EU, >> since privacy shield got canceled last July, there is not even a legal basis >> anymore that would allow you to do so at all.  In all cases, you would be >> held responsible for your customers data unless third-party is signing >> contracts with you to accept EU privacy laws.  EU has severe penalty for >> companies which break GDPR. > > Sorry, having to ask for permission because of laws does not constitute a > "severe privacy concern". Except in the sense that they're called privacy laws. Do you have a better wording? > That is completely outside of the scope of IETF and we should be pandering > to it. Making specifications that cannot be legally abided by is in IETF scope? Best Ale -- From nobody Tue Dec 22 11:34: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 410473A123D for ; Tue, 22 Dec 2020 11:33:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.199 X-Spam-Level: X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, 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 BSEvRlVboRMF for ; Tue, 22 Dec 2020 11:33:57 -0800 (PST) Received: from mail-il1-x131.google.com (mail-il1-x131.google.com [IPv6:2607:f8b0:4864:20::131]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B11433A1239 for ; Tue, 22 Dec 2020 11:33:57 -0800 (PST) Received: by mail-il1-x131.google.com with SMTP id t9so12998875ilf.2 for ; Tue, 22 Dec 2020 11:33:57 -0800 (PST) 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=C5sCenDVBykW6bFdtAgmC4XQ4KIAM52yDjduppVt+nw=; b=gMhuVeICq+Yi9iGVAYpcHAOd5vVwdgc2j0NgXWP3pCoqwUXcyT2xNe+xi/Kzlpu0ZF HVF1WcJqNS45hadAfleqBQx0gJjaxOIeOWzVNc5iVrwnuTvRjVA3kVg3mtCSc7jy+isg X/jOuCUjAosvjXswraKnjnt0SS7X65CO1bW04= 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=C5sCenDVBykW6bFdtAgmC4XQ4KIAM52yDjduppVt+nw=; b=s0SOVyP9v7YLuez4VOweMBe5OPy9L1hF7RcR02F07+U/mbvG8HISpuB2TPH36gJh3o A6w+gz4E1CI5b2cY7deRd+iWeFyrNc/dhxz5SCUkw2+eIIbyG+yFiJJ3pQi5b85EGy/Q fcKhbCbzaT0CLIwusQdSdlIDret8mcdYqRKtczQ8tg5f4PGIlzHEB+3zxmt4sWw9MtyA BnsBadzUZodpbsulLmT1JdD1+gDrpBLNPtw32ycFDyDhv81rhzSlSYgTVPnNH987e76p uzWSO5Foi3zn2wzODmwO5slQntkUTDy/6dKcluxAB1XTaEjOxqcQ3+Jl0ngO63s1pQU+ RuBA== X-Gm-Message-State: AOAM532qOb5NIqugYyaQ3HC4LmEbG7pk7QwJ16rC9py7vc0Ku6TF7Hpj DX+djLakENsfLpoeihUqCpS0ynwWI7VMbdC/eab8N5mJ9SXI3w== X-Google-Smtp-Source: ABdhPJx+0+PSvp42IqmUWM5IQlNNblE5zG+RQyBeL3+VBKAzFbf2jcwjRhqs0C7z3J26C29lSwybF1CAIUyR0lPNSyQ= X-Received: by 2002:a05:6e02:152f:: with SMTP id i15mr22056601ilu.104.1608665636581; Tue, 22 Dec 2020 11:33:56 -0800 (PST) MIME-Version: 1.0 References: <20201218023900.E73B82ACBB2B@ary.qy> <4a43ffaa-3987-c892-cce7-56f18888cdf5@tana.it> <39125012-e356-d62d-36fd-a7ff25a9f59f@taugh.com> <6bba023-d3d9-63a5-8441-11dac9a05e28@taugh.com> <74051a64-871a-db72-b5d9-1be374e23015@tana.it> <3034face-b6fc-0ce2-fa1b-f59210bd6f5b@tana.it> <46339b38-3b24-bcb7-5e73-8a97038ed69@taugh.com> <3997c81d-3b30-0823-a752-fb1d60a44593@tana.it> <448eeae1-2d82-91d3-4adf-cb547acd427a@mtcc.com> <0bf9fb2e-9974-4db3-3165-78508de3547c@mtcc.com> <44d92626-a13c-64e7-b1de-07cd50b1fd20@tana.it> In-Reply-To: <44d92626-a13c-64e7-b1de-07cd50b1fd20@tana.it> From: "Kurt Andersen (b)" Date: Tue, 22 Dec 2020 11:33:35 -0800 Message-ID: To: Alessandro Vesely Cc: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="000000000000d4cae405b712a7aa" Archived-At: Subject: Re: [dmarc-ietf] Ticket #55 - Clarify legal and privacy implications of failure reports X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Dec 2020 19:33:59 -0000 --000000000000d4cae405b712a7aa Content-Type: text/plain; charset="UTF-8" On Tue, Dec 22, 2020 at 11:00 AM Alessandro Vesely wrote: > > Making specifications that cannot be legally abided by is in IETF scope? > Sure - RFC 7258. Unless you want to play the semantic card of BCP vs. specification. --Kurt --000000000000d4cae405b712a7aa Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Dec 22, 2020 at 11:00 AM Alessand= ro Vesely <vesely@tana.it> wrot= e:

Making specifications that cannot be legally abided by is in IETF scope?

Sure - RFC 7258. Unless you want to play = the semantic card of BCP vs. specification.

--Kurt= =C2=A0
--000000000000d4cae405b712a7aa-- From nobody Tue Dec 22 11:41: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 EA4673A1250 for ; Tue, 22 Dec 2020 11:41:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, 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=mtcc.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 klLKZDrSUJse for ; Tue, 22 Dec 2020 11:41:10 -0800 (PST) Received: from mail-pl1-x630.google.com (mail-pl1-x630.google.com [IPv6:2607:f8b0:4864:20::630]) (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 1577C3A124E for ; Tue, 22 Dec 2020 11:41:09 -0800 (PST) Received: by mail-pl1-x630.google.com with SMTP id b8so7959513plx.0 for ; Tue, 22 Dec 2020 11:41:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mtcc.com; s=fluffulence; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=zUOeAH47I0sGbAbnKr45P7upKUaY23WZNy1jXAnLFcQ=; b=QL1Z/+Eq9FuSXm8NoXSrS5Y9CkB44BzZobQtoqVo/RZ1/mUABV4+A89tT6KNk1NWuq qruVmk21P0J6kayxO5DwFI2t7daAh48Eh6W/snRsiNvLA8yhNq0rgBn4azArtsPMGk3a BV9S0Ll3H1UcR8jEpaFVzZCZZDCASKw3P9buo6d4vser0CaB/a+RaIH2fMM+4q5EUVnn CKPS0zfUhzREjjsY7dZkQW6lXrgK397ebrhuQdDKzNSI1opyQYU4tuxO22nV1FjQEcDA W75O60wyTyK5bVzqIYxd1l/qwu5dOs9VTvcrx0t8rOnmbkStYgphXfyBNMOosnWY2OAQ sXLQ== 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=zUOeAH47I0sGbAbnKr45P7upKUaY23WZNy1jXAnLFcQ=; b=nP0GzEV0Jx1cn4DbZ4WYc/1LU6kdMsCuDBoWpdhJUCK30YWryrLZbnT31bTLRWxT5/ aP5JcFUsld+bELopOg/xMQqxu0lGip311L1dtqFofAocLe5duIz5m0C3n6+6LLyDqpbK IVqBXoXUfJBpMl3fZmmGWELXOWjpPJ/tKSLfD7ObQl+5jl8TkNjT9bk3YuwwF5u8zKTZ lO/KrYpD8/MQrM+NKaO3EPgZZwWCqp4eELxqeq2w3O18303hn7PjowApyLBJviS55azJ Dph+U16Pz3fS/eqQGTb+u3heaCFMuvWWPSaRoLQCibwn0g8oohkqkd48H2rB5WROWMO4 cwPw== X-Gm-Message-State: AOAM533G2Dt8nve8sU5MqomciJW0SGI8uy87B8TUR8RjnNRnpnLaty9m ub/I/aqF8z+t3kQZHdp5Oh24+TRcZckknQ== X-Google-Smtp-Source: ABdhPJx/AaIIQMo/HoyS4q1nBKL6ROV8tcPfgFWbKfmwAiqBORWuyrUV5MMJRSUrnQfBkwLjCaCbyw== X-Received: by 2002:a17:90a:e28a:: with SMTP id d10mr22782902pjz.77.1608666068551; Tue, 22 Dec 2020 11:41:08 -0800 (PST) Received: from mike-mac.lan ([107.182.37.0]) by smtp.gmail.com with ESMTPSA id k64sm21840437pfd.75.2020.12.22.11.41.07 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 22 Dec 2020 11:41:07 -0800 (PST) To: dmarc@ietf.org References: <20201218023900.E73B82ACBB2B@ary.qy> <4a43ffaa-3987-c892-cce7-56f18888cdf5@tana.it> <39125012-e356-d62d-36fd-a7ff25a9f59f@taugh.com> <6bba023-d3d9-63a5-8441-11dac9a05e28@taugh.com> <74051a64-871a-db72-b5d9-1be374e23015@tana.it> <3034face-b6fc-0ce2-fa1b-f59210bd6f5b@tana.it> <46339b38-3b24-bcb7-5e73-8a97038ed69@taugh.com> <3997c81d-3b30-0823-a752-fb1d60a44593@tana.it> <448eeae1-2d82-91d3-4adf-cb547acd427a@mtcc.com> <0bf9fb2e-9974-4db3-3165-78508de3547c@mtcc.com> <44d92626-a13c-64e7-b1de-07cd50b1fd20@tana.it> From: Michael Thomas Message-ID: Date: Tue, 22 Dec 2020 11:41:06 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 MIME-Version: 1.0 In-Reply-To: <44d92626-a13c-64e7-b1de-07cd50b1fd20@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] Ticket #55 - Clarify legal and privacy implications of failure reports X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Dec 2020 19:41:12 -0000 On 12/22/20 10:59 AM, Alessandro Vesely wrote: > >> Sorry, having to ask for permission because of laws does not >> constitute a "severe privacy concern". > > > Except in the sense that they're called privacy laws.  Do you have a > better wording? I don't know what was wrong with the initial text. But it most certainly is not a "severe privacy concern", especially if it is the originating domain getting the report. It already saw the original message in the first place assuming it wasn't spoofed, and if it was spoofed they are entitled to see it for forensics if the receiving domain is willing to send it to them. >> That is completely outside of the scope of IETF and we should be >> pandering >> to it. > > Making specifications that cannot be legally abided by is in IETF scope? > If the laws are unreasonable? Sure. We're not putting backdoors in for encryption either. It's their laws, let them figure it out. But you said that providers can get people to opt in, so that seem moot. Mike From nobody Wed Dec 23 01:16: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 9B7C73A0C93 for ; Wed, 23 Dec 2020 01:16:05 -0800 (PST) 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, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 R8JKC9McjZkC for ; Wed, 23 Dec 2020 01:16:03 -0800 (PST) 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 971C63A0C90 for ; Wed, 23 Dec 2020 01:16:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1608714959; bh=4kR8FKVIZd028KMWFfSWvXGyiPx6N6QStwT/1qiPdDs=; l=1833; h=To:References:From:Date:In-Reply-To; b=CDfD3sHnZGrEF4PUYautXzUsoDeznCDYvM3QTF3uRN/TNOD+LVgCmYAkk0l4RjoG8 mj64kD8AGUT1YK9TJY5+ZAwti1/mUJBNzgtRmB0St61g4hW36ho7wTeDQCwS20yWuE vFnrWHxV2ZIaw9JKt8mqdxRZrTVCiwBtg3odgjkXTkD5HX6A99mTod9VDv/h8 Authentication-Results: tana.it; auth=pass (details omitted) Original-From: Alessandro Vesely 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.000000005FE30ACE.000053D1; Wed, 23 Dec 2020 10:15:58 +0100 To: dmarc@ietf.org References: <20201218023900.E73B82ACBB2B@ary.qy> <4a43ffaa-3987-c892-cce7-56f18888cdf5@tana.it> <39125012-e356-d62d-36fd-a7ff25a9f59f@taugh.com> <6bba023-d3d9-63a5-8441-11dac9a05e28@taugh.com> <74051a64-871a-db72-b5d9-1be374e23015@tana.it> <3034face-b6fc-0ce2-fa1b-f59210bd6f5b@tana.it> <46339b38-3b24-bcb7-5e73-8a97038ed69@taugh.com> <3997c81d-3b30-0823-a752-fb1d60a44593@tana.it> <448eeae1-2d82-91d3-4adf-cb547acd427a@mtcc.com> <0bf9fb2e-9974-4db3-3165-78508de3547c@mtcc.com> <44d92626-a13c-64e7-b1de-07cd50b1fd20@tana.it> From: Alessandro Vesely Message-ID: <74b57d51-1ec3-dd48-7747-a57a7d74c709@tana.it> Date: Wed, 23 Dec 2020 10:15:58 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] Ticket #55 - Clarify legal and privacy implications of failure reports X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Dec 2020 09:16:06 -0000 On Tue 22/Dec/2020 20:41:06 +0100 Michael Thomas wrote: > On 12/22/20 10:59 AM, Alessandro Vesely wrote: >> >>> Sorry, having to ask for permission because of laws does not constitute a >>> "severe privacy concern". >> >> Except in the sense that they're called privacy laws.  Do you have a better >> wording? > > I don't know what was wrong with the initial text. But it most certainly is not > a "severe privacy concern", especially if it is the originating domain getting > the report. It already saw the original message in the first place assuming it > wasn't spoofed, and if it was spoofed they are entitled to see it for forensics > if the receiving domain is willing to send it to them. It may happen that the ruf= address ends up at the same submission server that issued the original message, but that's not guaranteed. John mentioned a real example. >>> That is completely outside of the scope of IETF and we should be pandering >>> to it. >> >> Making specifications that cannot be legally abided by is in IETF scope? > > If the laws are unreasonable? Sure. We're not putting backdoors in for > encryption either. It's their laws, let them figure it out. Failure reporting is rather akin to backdoors, in the sense that it can be used for pervasive monitoring. IMHO, GDPR is long winded and lacks practical design elements that could have inspired privacy-protecting protocols, but its intent is certainly not unreasonable. > But you said that providers can get people to opt in, so that seem moot. I'd recommend that software implements failure reporting, leaving it disabled with the possibility to enable it by domain in case of need. However, such recommendation would be an addition to the protocol, so it is not going to make it to the spec. Best Ale -- From nobody Wed Dec 23 01:16: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 8CDD73A0E77 for ; Wed, 23 Dec 2020 01:16:12 -0800 (PST) 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, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 jt5NtkyX93gK for ; Wed, 23 Dec 2020 01:16:09 -0800 (PST) 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 A436E3A0E7A for ; Wed, 23 Dec 2020 01:16:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1608714969; bh=vak0CrnmHxdiiuIoopLD2z/S5x2Hj3ZRXGx948bNeRE=; l=465; h=To:Cc:References:From:Date:In-Reply-To; b=BGfwfFW08KveYENKR+j+od2JVsT05s+O41aUU3yHEHPeMgHUpT1cG+P7psUt3XDFX Dl8cIiWdHLmeN4Dynf9WqBJMlsOiJZBgWLb9NWL7kaFwpPPatVgvQvDVnoKBIFeWQh 9n32TF86TtQ9bgFO5Gi7piKJU56t2LLCg1R5obtIkjK9h3SOq8d1HdyORPqh8 Authentication-Results: tana.it; auth=pass (details omitted) Original-From: Alessandro Vesely Original-Cc: "dmarc@ietf.org" 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 00000000005DC0CC.000000005FE30AD9.000053E6; Wed, 23 Dec 2020 10:16:08 +0100 To: "Kurt Andersen (b)" Cc: "dmarc@ietf.org" References: <20201218023900.E73B82ACBB2B@ary.qy> <4a43ffaa-3987-c892-cce7-56f18888cdf5@tana.it> <39125012-e356-d62d-36fd-a7ff25a9f59f@taugh.com> <6bba023-d3d9-63a5-8441-11dac9a05e28@taugh.com> <74051a64-871a-db72-b5d9-1be374e23015@tana.it> <3034face-b6fc-0ce2-fa1b-f59210bd6f5b@tana.it> <46339b38-3b24-bcb7-5e73-8a97038ed69@taugh.com> <3997c81d-3b30-0823-a752-fb1d60a44593@tana.it> <448eeae1-2d82-91d3-4adf-cb547acd427a@mtcc.com> <0bf9fb2e-9974-4db3-3165-78508de3547c@mtcc.com> <44d92626-a13c-64e7-b1de-07cd50b1fd20@tana.it> From: Alessandro Vesely Message-ID: <7c5f5933-2754-a7d5-b0e6-4b67c48873dd@tana.it> Date: Wed, 23 Dec 2020 10:16:08 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Ticket #55 - Clarify legal and privacy implications of failure reports X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Dec 2020 09:16:19 -0000 On Tue 22/Dec/2020 20:33:35 +0100 Kurt Andersen (b) wrote: > On Tue, Dec 22, 2020 at 11:00 AM Alessandro Vesely wrote: > >> Making specifications that cannot be legally abided by is in IETF scope? > > Sure - RFC 7258. Unless you want to play the semantic card of BCP vs. > specification. I don't get it. Do you mean that failure reporting can be assimilated to pervasive monitoring, and deserves mitigation as such? Best Ale -- From nobody Wed Dec 23 02:56:20 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4789F3A0EA4 for ; Wed, 23 Dec 2020 02:56:18 -0800 (PST) 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 HktZ-ztHO_lE for ; Wed, 23 Dec 2020 02:56:16 -0800 (PST) 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 71CEA3A0EA2 for ; Wed, 23 Dec 2020 02:56:16 -0800 (PST) Received: by mail-qv1-xf2e.google.com with SMTP id a4so7053713qvd.12 for ; Wed, 23 Dec 2020 02:56:16 -0800 (PST) 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=ibAk/LFXoDSS3oxWS3dBYV/KZBo0e5bavLqLSUBCrTE=; b=Ys0QbXDJTGk4L3sJAjgrUc7TeMTVDryMd73biIP+mdb8fNpUHwKkIghBBBa5PWwEYh OwFibzgi3wHq1Erq99zX6qj7l5XE+sPGgn2UaOCTCVQHuV6dl8QirKuFGSU2IcHfnzaK UwUbxXmpsYLhVuSrk30SjzrjVaBhPN5UUMJXI+9GIv2e7sru1ezuMhwffP7QfVcFm3et /loQl+08McbIsO0ECSoVkupMqfnlrnHkGPHJKYueEVWDYQ89wj6IMaXPGMdIHJZ6DQBU juR6ITr5lSNXQNlQkVbC/8MoTbNrbM52zh+QQmz8lMkpaOT87TqKILaOi8NttV1M8DDs BBZw== 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=ibAk/LFXoDSS3oxWS3dBYV/KZBo0e5bavLqLSUBCrTE=; b=Qi+HBxyKXyyVlz1nSnYvR8qTResD8D/435uhHBO2KqdPLrs2Pr8grd/vez2Gv0vcGX sDu+ttJZ4pTLz/+z6W4zFwiXaDIXdkd5KpcFQFDC5kZr3xR5fv1oqIZxXBywR41YRPV2 Udump1d/jUeTxlFYBVwLtI75kSHX6TNTStzZMwitH9p+N4XGtzmN1NPQsxBB1AcpOGWZ DWiXVZQCstim1dTF9eg/3ebN+/Ps0M4HwktEvmnrQUE84S5TkXhWSwJw2n/bP4hrQ2k/ SxasUWC0hpyLbJLbh3rZXqpDgoDR0rbV02VJQaYJmdOHJ7qCJM+kjPhiQdRCW3awKXzN jiXg== X-Gm-Message-State: AOAM531dfFkHxoF8zgkix/zyN6T375+SfFtdS+0R30n690suoJvwTDQU qm8GMOBb5sQEct1ZhUwxuVCqln3OcnoxH6Z3dZ0= X-Google-Smtp-Source: ABdhPJz/o/tUiQnyatqtY5guBJ37onH3gHO1e/MTdXwcKxjGe1b69eXgpDKX2+MlwQR81T/Zcm0ifqxt2HBFVavHCuI= X-Received: by 2002:a0c:dc13:: with SMTP id s19mr26504292qvk.26.1608720975462; Wed, 23 Dec 2020 02:56:15 -0800 (PST) MIME-Version: 1.0 References: <20201218023900.E73B82ACBB2B@ary.qy> <4a43ffaa-3987-c892-cce7-56f18888cdf5@tana.it> <39125012-e356-d62d-36fd-a7ff25a9f59f@taugh.com> <6bba023-d3d9-63a5-8441-11dac9a05e28@taugh.com> <74051a64-871a-db72-b5d9-1be374e23015@tana.it> <3034face-b6fc-0ce2-fa1b-f59210bd6f5b@tana.it> <46339b38-3b24-bcb7-5e73-8a97038ed69@taugh.com> <3997c81d-3b30-0823-a752-fb1d60a44593@tana.it> <74a5c37-19a6-6f6f-a51d-6e5cca5b29e8@taugh.com> In-Reply-To: <74a5c37-19a6-6f6f-a51d-6e5cca5b29e8@taugh.com> From: Dotzero Date: Wed, 23 Dec 2020 05:56:04 -0500 Message-ID: To: John R Levine Cc: Alessandro Vesely , IETF DMARC WG Content-Type: multipart/alternative; boundary="00000000000049070a05b71f8a87" Archived-At: Subject: Re: [dmarc-ietf] Ticket #55 - Clarify legal and privacy implications of failure reports X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Dec 2020 10:56:18 -0000 --00000000000049070a05b71f8a87 Content-Type: text/plain; charset="UTF-8" On Tue, Dec 22, 2020 at 11:39 AM John R Levine wrote: > I think that text is way too long and overspecific but we've already spent > too much time on this so I'll stop and see if there are other opinions. > > > On Tue, 22 Dec 2020, Alessandro Vesely wrote: > > OLD > > > > "Failure reports," or "failed message reports," provide diagnostic > > information about messages that a Mail Receiver has determined do not > > pass the DMARC mechanism. These reports are generally sent at the > > time such messages are received and evaluated, to provide the Domain > > Owner with timely notification that such failures are occurring, and > > to provide information that may assist in diagnosing the cause of the > > failures. > > > > > > NEW > > > > Failure reports provide detailed information about the failure of a > single > > message or a group of similar messages failing for the same reason. > They > > are meant to aid extreme cases where a domain owner is unable to > detect > why > > failures reported in aggregate form did occur. As an extension of > other > > kinds of failure notifications, these reports can contain either the > > content > > of a failed message or just its header. The latter characteristic > entails > > severe privacy concerns. For that reason, and because it turned out > not > to > > be important, failure reporting is usually disabled. > > The following is factually and technically incorrect: " The latter characteristic entails severe privacy concerns." The latter characteristic "the header". In fact, the full message can contain much more PII and/or PHI. > Regards, > John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY > Please consider the environment before reading this e-mail. https://jl.ly I agree with John. I'll go further and say that the working group should focus on what the IETF does best - technical specifications that involve interoperability - and avoid straying too far into the realms of law and politics. While the EU and GDPR may impact choices that operators make, there are other legal jurisdictions in the world. Further, my experience has been that many operators (receivers) only provide failure reports when contractual relationships (direct or indirect) exist between the parties involved. This can certainly meet the privacy requirements of GDPR and other privacy regulations. In conclusion, suppositional assertions such as " For that reason, and because it turned out not to be important, failure reporting is usually disabled." should not be included in the proposed standard. Could someone (anyone?) provide data that failure reports are not important? One example of the importance and usefulness of failure reports is for domains that actually have control of their mail flows. By pulling all the URLs from failure reports (received through a contracted party) and then removing all the URLs which we included in the mail that we had originally sent, all that was left was 100% badness and maliciousness. This significantly empowered our takedown efforts. Michael Hammer --00000000000049070a05b71f8a87 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Dec 22, 2020 at 11:39 AM John= R Levine <johnl@taugh.com> wr= ote:
I think tha= t text is way too long and overspecific but we've already spent
too much time on this so I'll stop and see if there are other opinions.=


On Tue, 22 Dec 2020, Alessandro Vesely wrote:
> OLD
>
>=C2=A0 =C2=A0"Failure reports," or "failed message repor= ts," provide diagnostic
>=C2=A0 =C2=A0information about messages that a Mail Receiver has determ= ined do not
>=C2=A0 =C2=A0pass the DMARC mechanism.=C2=A0 These reports are generall= y sent at the
>=C2=A0 =C2=A0time such messages are received and evaluated, to provide = the Domain
>=C2=A0 =C2=A0Owner with timely notification that such failures are occu= rring, and
>=C2=A0 =C2=A0to provide information that may assist in diagnosing the c= ause of the
>=C2=A0 =C2=A0failures.
>
>
> NEW
>
>=C2=A0 =C2=A0Failure reports provide detailed information about the fai= lure of a single
>=C2=A0 =C2=A0message or a group of similar messages failing for the sam= e reason.=C2=A0 They
>=C2=A0 =C2=A0are meant to aid extreme cases where a domain owner is una= ble to detect > why
>=C2=A0 =C2=A0failures reported in aggregate form did occur.=C2=A0 As an= extension of other
>=C2=A0 =C2=A0kinds of failure notifications, these reports can contain = either the > content
>=C2=A0 =C2=A0of a failed message or just its header.=C2=A0 The latter c= haracteristic entails
>=C2=A0 =C2=A0severe privacy concerns.=C2=A0 For that reason, and becaus= e it turned out not > to
>=C2=A0 =C2=A0be important, failure reporting is usually disabled.


The following is factually and technic= ally incorrect: " The latter characteristic entails severe privacy concerns." The latter= characteristic "the header". In fact, the full message can conta= in much more PII and/or PHI.
=C2=A0
Regards,
John Levine, johnl@tau= gh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

I agree with John. I'll go further and say that = the working group should focus on what the IETF does best - technical speci= fications that involve interoperability - and avoid straying too far into t= he realms of law and politics. While the EU and GDPR may impact choices tha= t operators make, there are other legal jurisdictions in the world. Further= , my experience has been that many operators (receivers) only provide failu= re reports when contractual relationships (direct or indirect) exist betwee= n the parties involved. This can certainly meet the privacy requirements of= GDPR and other privacy regulations.

In conclusion, suppo= sitional assertions such as " For that reason, and because it turned out not to be important, failure rep= orting is usually disabled." should not be included in the proposed st= andard. Could someone (anyone?) provide data that failure reports are not i= mportant? One example of the importance and usefulness of failure reports i= s for domains that actually have control of their mail flows. By pulling al= l the URLs from failure reports (received through a contracted party) and t= hen removing all the URLs which we included in the mail that we had origina= lly sent, all that was left was 100% badness and maliciousness. This signif= icantly empowered our takedown efforts.

Micha= el Hammer
--00000000000049070a05b71f8a87-- From nobody Wed Dec 23 09:14: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 C80393A0E6C for ; Wed, 23 Dec 2020 09:14:38 -0800 (PST) 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 TZX6GYl-aWmm for ; Wed, 23 Dec 2020 09:14:37 -0800 (PST) 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 A29313A0E6B for ; Wed, 23 Dec 2020 09:14:37 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01RTICXNQJ0G0057V6@mauve.mrochek.com> for dmarc@ietf.org; Wed, 23 Dec 2020 09:09:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mrochek.com; s=201712; t=1608743375; bh=yRCvVM7Zpf/GigDC9dILwXXkEwb3v9miSZi6xplD4fA=; h=From:Cc:Date:Subject:In-reply-to:References:To:From; b=fywfI+XXiw+qbc+jLfB0XHOUTSxghbhw9HJrryBg2hVVX4wyGTDcfVtj8JnLSIIyI r+tf778cAKvXRvGr2bM7eabTqWSDvEysPj0kHMj/28o5vJnJ5b/gdvXQljE84he//1 FNc8bB1Z8q5WMFCKmXxT9H90R35/Z5dVNaZ/aj58= MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=US-ASCII Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01RTI8T4T2BK0085YQ@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for dmarc@ietf.org; Wed, 23 Dec 2020 09:09:30 -0800 (PST) From: ned+dmarc@mrochek.com Cc: John R Levine , IETF DMARC WG , Alessandro Vesely Message-id: <01RTICXKLL3E0085YQ@mauve.mrochek.com> Date: Wed, 23 Dec 2020 08:54:01 -0800 (PST) In-reply-to: "Your message dated Wed, 23 Dec 2020 05:56:04 -0500" References: <20201218023900.E73B82ACBB2B@ary.qy> <4a43ffaa-3987-c892-cce7-56f18888cdf5@tana.it> <39125012-e356-d62d-36fd-a7ff25a9f59f@taugh.com> <6bba023-d3d9-63a5-8441-11dac9a05e28@taugh.com> <74051a64-871a-db72-b5d9-1be374e23015@tana.it> <3034face-b6fc-0ce2-fa1b-f59210bd6f5b@tana.it> <46339b38-3b24-bcb7-5e73-8a97038ed69@taugh.com> <3997c81d-3b30-0823-a752-fb1d60a44593@tana.it> <74a5c37-19a6-6f6f-a51d-6e5cca5b29e8@taugh.com> To: Dotzero Archived-At: Subject: Re: [dmarc-ietf] Ticket #55 - Clarify legal and privacy implications of failure reports X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Dec 2020 17:14:39 -0000 > On Tue, Dec 22, 2020 at 11:39 AM John R Levine wrote: > > I think that text is way too long and overspecific but we've already spent > > too much time on this so I'll stop and see if there are other opinions. > > > > > > On Tue, 22 Dec 2020, Alessandro Vesely wrote: > > > OLD > > > > > > "Failure reports," or "failed message reports," provide diagnostic > > > information about messages that a Mail Receiver has determined do not > > > pass the DMARC mechanism. These reports are generally sent at the > > > time such messages are received and evaluated, to provide the Domain > > > Owner with timely notification that such failures are occurring, and > > > to provide information that may assist in diagnosing the cause of the > > > failures. > > > > > > > > > NEW > > > > > > Failure reports provide detailed information about the failure of a single > > > message or a group of similar messages failing for the same reason. They > > > are meant to aid extreme cases where a domain owner is unable to detect why > > > failures reported in aggregate form did occur. As an extension of other > > > kinds of failure notifications, these reports can contain either the content > > > of a failed message or just its header. The latter characteristic entails > > > severe privacy concerns. For that reason, and because it turned out not to > > > be important, failure reporting is usually disabled. > The following is factually and technically incorrect: " The latter > characteristic entails severe privacy concerns." The latter characteristic > "the header". In fact, the full message can contain much more PII and/or > PHI. Quite right. It's also unforunate that we appear to be spending more arguing about what consistutes a legitimate privacy concern than reviewing proposed text. I also note that saying what's "usually done", even if currently correct, is at best the province of a BCP. It has no business being in a standard. > I agree with John. I'll go further and say that the working group should > focus on what the IETF does best - technical specifications that involve > interoperability - and avoid straying too far into the realms of law and > politics. While the EU and GDPR may impact choices that operators make, > there are other legal jurisdictions in the world. Further, my experience > has been that many operators (receivers) only provide failure reports when > contractual relationships (direct or indirect) exist between the parties > involved. This can certainly meet the privacy requirements of GDPR and > other privacy regulations. Agreed, but none of this belongs in the standard either. All the standard needs to say is that message header and bodies can contain personally identifiable information and that this may affect the choice of whether or not to send failure reports. Something like: Failure reports provide detailed information about the failure of a single message or a group of similar messages failing for the same reason. They are meant to aid in cases where a domain owner is unable to detect why failures reported in aggregate form did occur. It is important to note these reports can contain either the header or the entire content of a failed message, which in turn may contain personally identifiable information, which should be considered when decoding whether or not to generate such reports. Ned From nobody Wed Dec 23 10:10: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 4F7013A00F7 for ; Wed, 23 Dec 2020 10:10:34 -0800 (PST) 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 (2048-bit key) header.d=iecc.com header.b=Eexp3u/A; dkim=pass (2048-bit key) header.d=taugh.com header.b=Z3uhpdNe Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TR2X-U2UQwTT for ; Wed, 23 Dec 2020 10:10:32 -0800 (PST) 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 676433A00D9 for ; Wed, 23 Dec 2020 10:10:31 -0800 (PST) Received: (qmail 13865 invoked from network); 23 Dec 2020 18:10:30 -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=3627.5fe38816.k2012; i=johnl-iecc.com@submit.iecc.com; bh=f2kY3XXhNSjlknsGYEd3/087A2hOksgPwYDJuvLACdc=; b=Eexp3u/AuEDFrscXkTvSR7lzZOAOtTdZubJrz60u4ILiZXZrjKD/EG3047W4b5Q48o1I3MB8wL7oV0p10UuuGqMD3SyeliUiC/86XsDgJPxULlm9sTs+O0AQuVW7eP2E5OHfNRgsU3mNyBa2JnR66lJ0Q4A7FJX7P5pjhclL24Yk11Rt/UuwenHvh3UqtwTWMXAmzMOjrRpHeRHupoMDI2AeaK5+ah6aG+t+LecbqhDp0dWKDWhIK01t2rrEQAo4QKFR91P4xUsRacHeO8tui4EfVR4ylbow9A+M6G9DNnMvW+a87Ot0+EGSuD4yoFvrFpJDZb6/nh9dS+vIMg8+FQ== 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=3627.5fe38816.k2012; olt=johnl-iecc.com@submit.iecc.com; bh=f2kY3XXhNSjlknsGYEd3/087A2hOksgPwYDJuvLACdc=; b=Z3uhpdNeqj1uB0rGWntRI844Suj7urJbmqS5irj9kDpj/NsplctxxdovUr55tJew6kqxa95e3+zb7yRYvwDMza8CKlpjkc/Z27taIG4iz8WVRgGowG+TA498NT2BhzwWIsfQgIBlg4sHVdkCng4B5j5DJze9po+nmGOE51yP3b5k60XwA0VNykEVzHhbaehyZHyI+USmTYeltUv1PKYI+Q7ZM7s1cWq1HrBNwEHSLvDGq95OjWjEz51dQOWYNDEZaysj5n9I/ZBlVyItpPF9/+fGyylEh1B9xVfGyES02eHsoJ5Ns3Wr+tyNUovDVd0Oezoqv1u0rG/PGAFsyQcBJA== 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; 23 Dec 2020 18:10:30 -0000 Date: 23 Dec 2020 13:10:30 -0500 Message-ID: From: "John R Levine" To: "Ned Freed" Cc: "IETF DMARC WG" In-Reply-To: <01RTICXKLL3E0085YQ@mauve.mrochek.com> References: <20201218023900.E73B82ACBB2B@ary.qy> <4a43ffaa-3987-c892-cce7-56f18888cdf5@tana.it> <39125012-e356-d62d-36fd-a7ff25a9f59f@taugh.com> <6bba023-d3d9-63a5-8441-11dac9a05e28@taugh.com> <74051a64-871a-db72-b5d9-1be374e23015@tana.it> <3034face-b6fc-0ce2-fa1b-f59210bd6f5b@tana.it> <46339b38-3b24-bcb7-5e73-8a97038ed69@taugh.com> <3997c81d-3b30-0823-a752-fb1d60a44593@tana.it> <74a5c37-19a6-6f6f-a51d-6e5cca5b29e8@taugh.com> <01RTICXKLL3E0085YQ@mauve.mrochek.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [dmarc-ietf] Ticket #55 - Clarify legal and privacy implications of failure reports X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Dec 2020 18:10:34 -0000 On Wed, 23 Dec 2020, Ned Freed wrote: > Failure reports provide detailed information about the failure of a single > message or a group of similar messages failing for the same reason. They > are meant to aid in cases where a domain owner is unable to detect why > failures reported in aggregate form did occur. It is important to note > these reports can contain either the header or the entire content of a > failed message, which in turn may contain personally identifiable > information, which should be considered when decoding whether or not to > generate such reports. Ship it. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From nobody Wed Dec 23 11:49: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 6192B3A09A4 for ; Wed, 23 Dec 2020 11:49:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.499 X-Spam-Level: X-Spam-Status: No, score=-17.499 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, HTTPS_HTTP_MISMATCH=0.1, 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 ogaZFZkqcSv4 for ; Wed, 23 Dec 2020 11:49:34 -0800 (PST) Received: from mail-lf1-x130.google.com (mail-lf1-x130.google.com [IPv6:2a00:1450:4864:20::130]) (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 C58AE3A0994 for ; Wed, 23 Dec 2020 11:49:33 -0800 (PST) Received: by mail-lf1-x130.google.com with SMTP id y19so42530304lfa.13 for ; Wed, 23 Dec 2020 11:49:33 -0800 (PST) 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=Wg6vnNpZmWg0T7AvZEODSNDoqwVnwytRwhC48ECevVA=; b=ecqU5tR9yxROrPNywzwyoiVHOAHoGTPgvycyn6CBLv/2XKQswbmjuBHUQHxuLhi9N7 4j0DODs/YLP5tdon8kQAdCdOTF3dC46dB8Tty3RaGxRTNlnaEmJ/u4vxmB0ZDa5Zc0OM TmoEFhYtyPPmDkx3i1+fM3OQ55vClaV7VWk/1cHhTh/kpVQr/CPCIPA6yXXpWaPiljvM 6D9DKa0TRbNPGLEMzTXuDRaCP/+CJgjWaqqvaekeVy4A3ab3URNZP+9UsWWtKRdbuLTl PydpOeXtfTss+BdpfG+Fv6SO/ylnwSiLIY+plsgZUJ93a5Jgr1QgGnHKeHRmENtlGTwB AyLg== 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=Wg6vnNpZmWg0T7AvZEODSNDoqwVnwytRwhC48ECevVA=; b=b/giHkDV90QjOkdlK2dKYBQv8wf8DFsczRrKq3IM0TRfAGGfOeD0miPujrw2M7Nmy+ x7d/+Qc2f+wMg1WwAT+ziRp05Vs/G54WoIn/WhOxqhPyCPukKU7O9T4N3dHnfnt2bgjK 0/b/n9L59TC9An2F62IXPWoOwxET4eglj/8rCAPhGJ8vCEIS1CxJh5Twm2dLbMmeS05d T1w6WTFhs9th3QcxpKZ88j11DnE+AKmsFKzoLBIaXbAY0m1oOwYAM5jdcEMkdnKP6Cdk d0M5g4aA7zIskRIX5bV9CZcqTWujJmUrvMsNeUqVSikPO1l9Pxvc8V2qSL8Sa3J+wlKY MGpA== X-Gm-Message-State: AOAM531qq9KbDK9l3MSBRUK1RKPa2c8hP8SDoiivDM/JYmv8lb+q/JyN L1Dzvxbdjs4OE3AOjTM7pAYl8C5opmgznfdf5xUA6AGIK+Lvkw== X-Google-Smtp-Source: ABdhPJzNMShJvSlKMwtByeaG+EvKJkcavqUPPt8TgBOeOY3kL4zRWLL3iR5L0yRBoL9XrcAs+zWKRJXXXcmHXF0xcVo= X-Received: by 2002:a2e:8113:: with SMTP id d19mr11629884ljg.303.1608752971150; Wed, 23 Dec 2020 11:49:31 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Emil Gustafsson Date: Wed, 23 Dec 2020 11:49:19 -0800 Message-ID: To: "Brotman, Alex" Cc: Marc Bradshaw , DMARC IETF Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="0000000000006ab52305b726fd06" Archived-At: Subject: Re: [dmarc-ietf] Discussion - ARC/Extensible Reporting (Ticket #56) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 23 Dec 2020 19:49:38 -0000 --0000000000006ab52305b726fd06 Content-Type: multipart/alternative; boundary="00000000000060dab805b726fd22" --00000000000060dab805b726fd22 Content-Type: text/plain; charset="UTF-8" While the common format would be great as a consumer of reports, I'm wondering how many different reports there would be. New auth standards don't pop up that often, so what other reports are you thinking about? I can see two obvious candidates; the mailserver software and the spam/abuse prevention software. It would be interesting to support something like that too but shouldn't those just put the results inside the dkim/spf/arc auth_results? /E On Tue, Dec 8, 2020 at 12:29 PM Brotman, Alex wrote: > I feel (as a receiver of reports) as though another reason to have these > as a single report is so that the receiver of the report is able to more > easily correlate the data/times. I should be able to believe that all > reports (without a specified ri) will be 0000-2359, though things happen, > and systems break down. > > > > -- > > Alex Brotman > > Sr. Engineer, Anti-Abuse & Messaging Policy > > Comcast > > > > *From:* dmarc *On Behalf Of * Marc Bradshaw > *Sent:* Monday, December 7, 2020 5:17 PM > *To:* DMARC IETF > *Subject:* Re: [dmarc-ietf] Discussion - ARC/Extensible Reporting (Ticket > #56) > > > > > > There is value in including these in one report, especially where the > extended property being reported on influences how DMARC is evaluated. > > > > Using ARC as the example, when a p=reject policy was overriden by the > receiver because of an ARC evaluation, when that data is included in the > report the indirect mail flow can be clearly seen, which would not be the > case if ARC were included as a separate report. > > > > This could be included in an element, or could be included > directly in the auth_results section of the report, based on an assumption > that the things being reported SHOULD have an authentication results entry > in processed mail. > > > > > > ... > > ... > > (as defined in arc standard) > > (as defined in foo standard) > > > > > > These would be defined in a registry with reference to each standard, and > parsers would ignore any sections they did not understand. > > > > On Fri, 4 Dec 2020, at 6:43 AM, Alessandro Vesely wrote: > > On Thu 03/Dec/2020 19:54:51 +0100 Brotman, Alex wrote: > > > > > >> -----Original Message----- > > >> From: dmarc On Behalf Of Alessandro Vesely > > >> Sent: Thursday, December 3, 2020 6:24 AM > > >> To: dmarc@ietf.org > > >> Subject: Re: [dmarc-ietf] Discussion - ARC/Extensible Reporting (Ticket > #56) > > >> > > >> On Wed 02/Dec/2020 20:46:54 +0100 Brotman, Alex wrote: > > >>> > > >>> While this ticket/enhancement specifically mentions ARC, I could > > >>> perhaps see the usefulness in other places. It seems like it would be > > >>> more beneficial to create a method by which other documents could > > >>> provide XML- based "extensions" to the report. This would allow > > >>> mechanisms relying on DMARC to independently define their reporting > > >>> schema to be included in DMARC aggregate reports. Alternately, we > could > > >>> focus specifically on ARC, and work to include that in the base XML. > > >>> This means that any later reporting requirements could again require > > >>> changes to the core drafts.>>> > > >> > > >> > > >> Another possibility is for ARC to define its own report format. > Hijacking > > >> rua= targets to send a different kind of report should be allowed. > > >> Otherwise, we could define a new tag, e.g. rue= (e for Extension).>> > > >> In either case, as we're introduce variations in aggregate report > content, > > >> we have to devise a method for determining what version/kind of report > is > > >> attached to a given message.>> > > > > > > We could add an element called "", and we allow ARC or > whatever > > > it may be to exist under that element. The Aggregate Reporting document > > > needs to specify that any extensions are expected to be proper XML, and > if > > > there are no extensions, an empty element is sufficient. We could > create a > > > bit more structure as a requirement if we wanted:> > > > > > > standard="ARC_DMARC_REPORTING_EXTENSION_DEFINITION"> > > > ... (as defined in referenced standard) > > > > > > > > > > > > If a report parser doesn't know what ARC is (or any of the extensions), > it could skip the processing. I do understand this means that > element may break existing parsers, even when empty, though, I expect many > of the things we're proposing may fracture the expected XML. > > > > > > We can do a better job at producing aggregate reports with an > automatically verifiable content. For example, prepending stuff like this: > > > > > > > xmlns:dmarc="http://dmarc.org/dmarc-xml/0.1 > > " > > xs:schemaLocation="http://dmarc.org/dmarc-xml/0.1 > > rua.xsd"> > > > > ... > > > > (Perhaps something better than "http://dmarc.org/dmarc-xml/0.1 > " > for the version) > > > > But then, would the imply dmarc-xml grammar should be > upgraded every time ARC (or whatever) is upgraded? > > > > Separate reports sounds simpler. > > > > > > Best > > Ale > > -- > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > dmarc mailing list > > dmarc@ietf.org > > https://www.ietf.org/mailman/listinfo/dmarc > > > > > > > -- > > Marc Bradshaw > > marcbradshaw.net > > | @marcbradshaw > > > > > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > --00000000000060dab805b726fd22 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
While the common format would be great as a consumer of re= ports, I'm wondering how many different=C2=A0reports there would be. Ne= w auth standards don't pop up that often, so what other reports are you= thinking about? I can see two obvious candidates; the mailserver=C2=A0soft= ware and the spam/abuse prevention software. It would be interesting to sup= port something like that too but shouldn't those just put the results i= nside the dkim/spf/arc auth_results?
/E

On Tue, Dec 8, 2020 at 12:= 29 PM Brotman, Alex <Alex_Brotman=3D40comcast.com@dmarc.ietf.org> wrote:

I feel (as a receiver of reports) as though another = reason to have these as a single report is so that the receiver of the repo= rt is able to more easily correlate the data/times.=C2=A0 I should be able = to believe that all reports (without a specified ri) will be 0000-2359, though things happen, and systems break d= own.

=C2=A0

--

Alex Brotman

Sr. Engineer, Anti-Abuse & Messaging Policy

Comcast

=C2=A0

From: dmarc <dmarc-bounces@ietf.org> On Behalf = Of Marc Bradshaw
Sent: Monday, December 7, 2020 5:17 PM
To: DMARC IETF <dmarc@ietf.org>
Subject: Re: [dmarc-ietf] Discussion - ARC/Extensible Reporting (Tic= ket #56)

=C2=A0

=C2=A0

There is value in including these in one report, esp= ecially where the extended property being reported on influences how DMARC = is evaluated.

=C2=A0

Using ARC as the example, when a p=3Dreject policy w= as overriden by the receiver because of an ARC evaluation, when that data i= s included in the report the indirect mail flow can be clearly seen, which = would not be the case if ARC were included as a separate report.

=C2=A0

This could be included in an <extension> eleme= nt, or could be included directly in the auth_results section of the report= , based on an assumption that the things being reported SHOULD have an auth= entication results entry in processed mail.

=C2=A0

<auth_results>=

<dkim>...</dkim>

<spf>...</spf><= /u>

<arc> (as defined in arc standard) <= ;/arc>

<foo> (as defined in foo standard) <= ;/foo>

</auth_results>

=C2=A0

These would be defined in a registry with reference = to each standard, and parsers would ignore any sections they did not unders= tand.

=C2=A0

On Fri, 4 Dec 2020, at 6:43 AM, Alessandro Vesely wr= ote:

On Thu 03/Dec/2020 19:54:51 +0100 Brotman, Alex wrot= e:

>=C2=A0

>> -----Original Message-----

>> From: dmarc <dmarc-bounces@ietf.org> On Behalf O= f Alessandro Vesely

>> Sent: Thursday, December 3, 2020 6:24 AM=

>> To:=C2=A0dmarc@ietf.org

>> Subject: Re: [dmarc-ietf] Discussion - ARC/= Extensible Reporting (Ticket #56)

>>=C2=A0

>> On Wed 02/Dec/2020 20:46:54 +0100 Brotman, = Alex wrote:

>>>=C2=A0

>>> While this ticket/enhancement specifica= lly mentions ARC, I could

>>> perhaps see the usefulness in other pla= ces.=C2=A0 It seems like it would be

>>> more beneficial to create a method by w= hich other documents could

>>> provide XML- based "extensions&quo= t; to the report.=C2=A0 This would allow

>>> mechanisms relying on DMARC to independ= ently define their reporting

>>> schema to be included in DMARC aggregat= e reports.=C2=A0 Alternately, we could

>>> focus specifically on ARC, and work to = include that in the base XML.

>>> This means that any later reporting req= uirements could again require

>>> changes to the core drafts.>>>=

>>=C2=A0

>>=C2=A0

>> Another possibility is for ARC to define it= s own report format.=C2=A0 Hijacking

>> rua=3D targets to send a different kind of = report should be allowed.

>> Otherwise, we could define a new tag, e.g. = rue=3D (e for Extension).>>

>> In either case, as we're introduce vari= ations in aggregate report content,

>> we have to devise a method for determining = what version/kind of report is=C2=A0

>> attached to a given message.>>=

>=C2=A0

> We could add an element called "<extens= ions>", and we allow ARC or whatever

> it may be to exist under that element.=C2=A0 Th= e Aggregate Reporting document

> needs to specify that any extensions are expect= ed to be proper XML, and if

> there are no extensions, an empty element is su= fficient.=C2=A0 We could create a

> bit more structure as a requirement if we wante= d:>=C2=A0

> <extensions>

>=C2=A0=C2=A0=C2=A0 <extension name=3D"ar= c" standard=3D"ARC_DMARC_REPORTING_EXTENSION_DEFINITION">=

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ... (as defined i= n referenced standard)

>=C2=A0=C2=A0=C2=A0 </extension><= /u>

> </extensions>

>=C2=A0

> If a report parser doesn't know what ARC is= (or any of the extensions), it could skip the processing.=C2=A0 I do under= stand this means that <extensions> element may break existing parsers= , even when empty, though, I expect many of the things we're proposing may fracture the expected XML.

=C2=A0

=C2=A0

We can do a better job at producing aggregate report= s with an automatically verifiable content.=C2=A0 For example, prepending s= tuff like this:

=C2=A0

<?xml version=3D"1.0" encoding=3D"= UTF-8"?>

<dmarc:feedback xmlns:xs=3D"http://www.w3.org/2001/XMLSchema-instance"

xs:schemaLocation=3D"htt= p://dmarc.org/dmarc-xml/0.1 rua.xsd">

<report_metadata>

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ...

=C2=A0

(Perhaps something better than "http://dmarc.org/dmarc-xml/0.1" for the version)=

=C2=A0

But then, would the <extensions> imply dmarc-x= ml grammar should be upgraded every time ARC (or whatever) is upgraded?<= /u>

=C2=A0

Separate reports sounds simpler.

=C2=A0

=C2=A0

Best

Ale

--=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

_______________________________________________

dmarc mailing list

=C2=A0

=C2=A0

--

=C2=A0 Marc Bradshaw

=C2=A0=C2=A0marcbradshaw.net |= =C2=A0@marcbradshaw

=C2=A0

=C2=A0

_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
--00000000000060dab805b726fd22-- --0000000000006ab52305b726fd06 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIPlAYJKoZIhvcNAQcCoIIPhTCCD4ECAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ggzuMIIEtjCCA56gAwIBAgIQeAMYYHb81ngUVR0WyMTzqzANBgkqhkiG9w0BAQsFADBMMSAwHgYD VQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEGA1UE AxMKR2xvYmFsU2lnbjAeFw0yMDA3MjgwMDAwMDBaFw0yOTAzMTgwMDAwMDBaMFQxCzAJBgNVBAYT AkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSowKAYDVQQDEyFHbG9iYWxTaWduIEF0bGFz IFIzIFNNSU1FIENBIDIwMjAwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCvLe9xPU9W dpiHLAvX7kFnaFZPuJLey7LYaMO8P/xSngB9IN73mVc7YiLov12Fekdtn5kL8PjmDBEvTYmWsuQS 6VBo3vdlqqXZ0M9eMkjcKqijrmDRleudEoPDzTumwQ18VB/3I+vbN039HIaRQ5x+NHGiPHVfk6Rx c6KAbYceyeqqfuJEcq23vhTdium/Bf5hHqYUhuJwnBQ+dAUcFndUKMJrth6lHeoifkbw2bv81zxJ I9cvIy516+oUekqiSFGfzAqByv41OrgLV4fLGCDH3yRh1tj7EtV3l2TngqtrDLUs5R+sWIItPa/4 AJXB1Q3nGNl2tNjVpcSn0uJ7aFPbAgMBAAGjggGKMIIBhjAOBgNVHQ8BAf8EBAMCAYYwHQYDVR0l BBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYDVR0OBBYEFHzM CmjXouseLHIb0c1dlW+N+/JjMB8GA1UdIwQYMBaAFI/wS3+oLkUkrk1Q+mOai97i3Ru8MHsGCCsG AQUFBwEBBG8wbTAuBggrBgEFBQcwAYYiaHR0cDovL29jc3AyLmdsb2JhbHNpZ24uY29tL3Jvb3Ry MzA7BggrBgEFBQcwAoYvaHR0cDovL3NlY3VyZS5nbG9iYWxzaWduLmNvbS9jYWNlcnQvcm9vdC1y My5jcnQwNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9yb290LXIz LmNybDBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIGCCsGAQUFBwIBFiZodHRwczovL3d3dy5n bG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG9w0BAQsFAAOCAQEANyYcO+9JZYyqQt41 TMwvFWAw3vLoLOQIfIn48/yea/ekOcParTb0mbhsvVSZ6sGn+txYAZb33wIb1f4wK4xQ7+RUYBfI TuTPL7olF9hDpojC2F6Eu8nuEf1XD9qNI8zFd4kfjg4rb+AME0L81WaCL/WhP2kDCnRU4jm6TryB CHhZqtxkIvXGPGHjwJJazJBnX5NayIce4fGuUEJ7HkuCthVZ3Rws0UyHSAXesT/0tXATND4mNr1X El6adiSQy619ybVERnRi5aDe1PTwE+qNiotEEaeujz1a/+yYaaTY+k+qJcVxi7tbyQ0hi0UB3myM A/z2HmGEwO8hx7hDjKmKbDCCA18wggJHoAMCAQICCwQAAAAAASFYUwiiMA0GCSqGSIb3DQEBCwUA MEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAtIFIzMRMwEQYDVQQKEwpHbG9iYWxTaWdu MRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTA5MDMxODEwMDAwMFoXDTI5MDMxODEwMDAwMFowTDEg MB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24xEzAR BgNVBAMTCkdsb2JhbFNpZ24wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDMJXaQeQZ4 Ihb1wIO2hMoonv0FdhHFrYhy/EYCQ8eyip0EXyTLLkvhYIJG4VKrDIFHcGzdZNHr9SyjD4I9DCuu l9e2FIYQebs7E4B3jAjhSdJqYi8fXvqWaN+JJ5U4nwbXPsnLJlkNc96wyOkmDoMVxu9bi9IEYMpJ pij2aTv2y8gokeWdimFXN6x0FNx04Druci8unPvQu7/1PQDhBjPogiuuU6Y6FnOM3UEOIDrAtKeh 6bJPkC4yYOlXy7kEkmho5TgmYHWyn3f/kRTvriBJ/K1AFUjRAjFhGV64l++td7dkmnq/X8ET75ti +w1s4FRpFqkD2m7pg5NxdsZphYIXAgMBAAGjQjBAMA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8E BTADAQH/MB0GA1UdDgQWBBSP8Et/qC5FJK5NUPpjmove4t0bvDANBgkqhkiG9w0BAQsFAAOCAQEA S0DbwFCq/sgM7/eWVEVJu5YACUGssxOGhigHM8pr5nS5ugAtrqQK0/Xx8Q+Kv3NnSoPHRHt44K9u bG8DKY4zOUXDjuS5V2yq/BKW7FPGLeQkbLmUY/vcU2hnVj6DuM81IcPJaP7O2sJTqsyQiunwXUaM ld16WCgaLx3ezQA3QY/tRG3XUyiXfvNnBB4V14qWtNPeTCekTBtzc3b0F5nCH3oO4y0IrQocLP88 q1UOD5F+NuvDV0m+4S4tfGCLw0FREyOdzvcya5QBqJnnLDMfOjsl0oZAzjsshnjJYS8Uuu7bVW/f hO4FCU29KNhyztNiUGUe65KXgzHZs7XKR1g/XzCCBM0wggO1oAMCAQICEAGNZbQJqBdAMtoTq8Du WfEwDQYJKoZIhvcNAQELBQAwVDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYt c2ExKjAoBgNVBAMTIUdsb2JhbFNpZ24gQXRsYXMgUjMgU01JTUUgQ0EgMjAyMDAeFw0yMDA5MDgy MzM5MzBaFw0yMTAzMDcyMzM5MzBaMCAxHjAcBgkqhkiG9w0BCQEWD2VtZ3VAZ29vZ2xlLmNvbTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAOdltLLFkDZcnb4L/2kIWbg7aaipTwuyhHkV r/fuG6W0W6tdDF1vUAG6RDO1eMG6ePrZMjGzB9Pu7kzZGN+glhn6k6a/Ef8uFKmOFH2XwJewg4VE QFAdSoq9cpbWds2cNIn0OKj+VNyqlahB2+WzlarkxSePUqp3kQrplF4wsgEf1GwBw19OA2dScLBE kGaSdZN1jxVQQ3/3ReVFuTg7b5CYDrpVgkzPpGqMCsK5aVTrAbrKV/EfT3IZix0OUXH3VzRO34q8 CHqUaX1EQ9wB5n/sHAgOzhvKrVmUN6UtEa+yMKBLFnwCUqik0GOKhIpzocxiLz/7rfDOt4gImc1D 6JcCAwEAAaOCAc0wggHJMBoGA1UdEQQTMBGBD2VtZ3VAZ29vZ2xlLmNvbTAOBgNVHQ8BAf8EBAMC BaAwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMB0GA1UdDgQWBBQmzfIaY6uE4rvRwKBy PY89Q+o//DBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIGCCsGAQUFBwIBFiZodHRwczovL3d3 dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzAJBgNVHRMEAjAAMIGaBggrBgEFBQcBAQSBjTCB ijA+BggrBgEFBQcwAYYyaHR0cDovL29jc3AuZ2xvYmFsc2lnbi5jb20vY2EvZ3NhdGxhc3Izc21p bWVjYTIwMjAwSAYIKwYBBQUHMAKGPGh0dHA6Ly9zZWN1cmUuZ2xvYmFsc2lnbi5jb20vY2FjZXJ0 L2dzYXRsYXNyM3NtaW1lY2EyMDIwLmNydDAfBgNVHSMEGDAWgBR8zApo16LrHixyG9HNXZVvjfvy YzBGBgNVHR8EPzA9MDugOaA3hjVodHRwOi8vY3JsLmdsb2JhbHNpZ24uY29tL2NhL2dzYXRsYXNy M3NtaW1lY2EyMDIwLmNybDANBgkqhkiG9w0BAQsFAAOCAQEADr/e4M1+D/oNeKTsHqGHJsCiJ294 gqHJxZMx/LZcBXqrvI26AFr+qwal/GD0M1LJYzZI4XO5Bt2S06+yDd58jEARFo487jZzvrKuVakW S55g9vER08AkFsV2sMG5DRewCaQYQPc5uJce1IOX+PdGZlDdJImxenpfdKRqTfJC5hoeeY1JSSlV /91lFpQ3g5z1MLCwbF7O17pApsSOqJk6kfMDpKiub29C2egC+Z3Rl2skPAkrJa/pZqrViuB7QDhM 9rlr7OOWXRtQYR+lES69+oB5sf15gxDeW7idWNOjFKLfHrW2+kZyg3B/aIKiOhbJG8gbuXBEFh7t yOXQWmR0CDGCAmowggJmAgEBMGgwVDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExKjAoBgNVBAMTIUdsb2JhbFNpZ24gQXRsYXMgUjMgU01JTUUgQ0EgMjAyMAIQAY1ltAmo F0Ay2hOrwO5Z8TANBglghkgBZQMEAgEFAKCB1DAvBgkqhkiG9w0BCQQxIgQg4ZznHj5pzzIlaCA1 dTGEK4cy1L0N2/SCerxRyCbLzt4wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0B CQUxDxcNMjAxMjIzMTk0OTMxWjBpBgkqhkiG9w0BCQ8xXDBaMAsGCWCGSAFlAwQBKjALBglghkgB ZQMEARYwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMAsGCSqGSIb3DQEBCjALBgkqhkiG9w0BAQcw CwYJYIZIAWUDBAIBMA0GCSqGSIb3DQEBAQUABIIBAIU0mMtwJiuDCyjFECmgA8vgZWjNlmsgBLwK bUXOrdNZkYgoplePi+DzUXK/navursCKn+69AdWQSuenRMLd063Qn5rjlucSX/uof2eg+T2gF90T LSJW7sP7oQxctYGopYlFq3Y8WoWuwK9veTLcKqVVbeYbV6WQvVhfLVrAeTho3FXCfirTywJphFpW AlHHjCDTLhrlOWM2EINogtKDy2ZLoGR4FLsiRwU7wQIdX8dMKB5/CRrfLPr/qn3zqpjrALNvrKT/ FUhhPTXRNosOOdGzenIPMloR7pOeA5sCWsyqlINOOPvpY5Nd4Ohs4EM03QffVqcMGXN2piCnDRnb f5g= --0000000000006ab52305b726fd06-- From nobody Wed Dec 23 12:03: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 477013A09C6 for ; Wed, 23 Dec 2020 12:03:43 -0800 (PST) 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 2vdFq8p8FFZy for ; Wed, 23 Dec 2020 12:03:41 -0800 (PST) Received: from mail-il1-x131.google.com (mail-il1-x131.google.com [IPv6:2607:f8b0:4864:20::131]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 800B63A0994 for ; Wed, 23 Dec 2020 12:03:41 -0800 (PST) Received: by mail-il1-x131.google.com with SMTP id q5so171788ilc.10 for ; Wed, 23 Dec 2020 12:03:41 -0800 (PST) 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=/NYQL92puAaZPdVN5md3FwQGB+CgKIRpzds8Gyl0dCk=; b=KgkkdXtJxvjBeFlp4TSGoObzddYsgE2WNnsPW5UotA7Y83nkVoiP7C/hnlqjYTlGZK etVBvckvITKUZVUdqVor4rORDtRQR++RuyDOSbbqfK3NPepFeLwwTu1aJSjBHW2eTtKQ 85xGRAXBi+JR+XTFUneMQRbBtpBYO0SxIr4Nc= 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=/NYQL92puAaZPdVN5md3FwQGB+CgKIRpzds8Gyl0dCk=; b=cUaX0TaonMv97QCtL2iXP1uSLI4zEry1w11uEeOoZVjjVa3Y07mdsMrOKgdR+Rvv9o 8osrpaX/uBQuiEucxnsX3uk6+aqftraT2iZp3wGMLRoFJ/3F3XswHlt35h78+3ELXGvx wMxjYG05gvzR12Mab2hn3NhXe0VZDxdfRK5R4Q4lhwmLkFAzvA/k6O0WK+na1P83bxuk af/iOxjTco9K75qwoVJJLY54r2KP2UbDX+CFbRtr/wfYqo3GAGLidmfKaSIa9+Nr+Flo 3YmvVQZv/31F2TA9cAgU3MtvY+CS9Q0rMI9JhJUzypn7IVZ41hz4QmeKB6sFHX1IxSo8 LR3g== X-Gm-Message-State: AOAM533sSNDbslK3jYAdSefwwKiCnUzQiYVgpJlzoqtW1g2G6WHZ94OR NY6AWIC0K4JAJIMUztoleDeFGBcWAEk9GeUIz9O66tVQKg/9Ww== X-Google-Smtp-Source: ABdhPJyx+UVHQB+7fGnajFen9zLmkM0J6kdFPb0bCwnS//QeBUZvdRtC/GX1ZOyMKl6aB4BYOJEx3ia+XMntKot9nHM= X-Received: by 2002:a92:9f15:: with SMTP id u21mr28614607ili.120.1608753820685; Wed, 23 Dec 2020 12:03:40 -0800 (PST) MIME-Version: 1.0 References: <20201218023900.E73B82ACBB2B@ary.qy> <4a43ffaa-3987-c892-cce7-56f18888cdf5@tana.it> <39125012-e356-d62d-36fd-a7ff25a9f59f@taugh.com> <6bba023-d3d9-63a5-8441-11dac9a05e28@taugh.com> <74051a64-871a-db72-b5d9-1be374e23015@tana.it> <3034face-b6fc-0ce2-fa1b-f59210bd6f5b@tana.it> <46339b38-3b24-bcb7-5e73-8a97038ed69@taugh.com> <3997c81d-3b30-0823-a752-fb1d60a44593@tana.it> <74a5c37-19a6-6f6f-a51d-6e5cca5b29e8@taugh.com> <01RTICXKLL3E0085YQ@mauve.mrochek.com> In-Reply-To: From: "Kurt Andersen (b)" Date: Wed, 23 Dec 2020 12:03:28 -0800 Message-ID: To: John R Levine Cc: Ned Freed , IETF DMARC WG Content-Type: multipart/alternative; boundary="00000000000003702d05b72730f9" Archived-At: Subject: Re: [dmarc-ietf] Ticket #55 - Clarify legal and privacy implications of failure reports X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Dec 2020 20:03:43 -0000 --00000000000003702d05b72730f9 Content-Type: text/plain; charset="UTF-8" On Wed, Dec 23, 2020 at 10:10 AM John R Levine wrote: > On Wed, 23 Dec 2020, Ned Freed wrote: > > Failure reports provide detailed information about the failure of a > single > > message or a group of similar messages failing for the same reason. They > > are meant to aid in cases where a domain owner is unable to detect why > > failures reported in aggregate form did occur. It is important to note > > these reports can contain either the header or the entire content of a > > failed message, which in turn may contain personally identifiable > > information, which should be considered when decoding whether or not to > > generate such reports. > > Ship it. > With one minor correction, I agree. The minor correction is in the last sentence: s/decoding/deciding/ --Kurt --00000000000003702d05b72730f9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Dec 23, 2020 at 10:10 AM John R L= evine <johnl@taugh.com> wrote:=
On Wed, 23 Dec 2020, Ned Freed wrote:
>=C2=A0 Failure reports provide detailed information about the failure o= f a single
>=C2=A0 message or a group of similar messages failing for the same reas= on. They
>=C2=A0 are meant to aid in cases where a domain owner is unable to dete= ct why
>=C2=A0 failures reported in aggregate form did occur. It is important t= o note
>=C2=A0 these reports can contain either the header or the entire conten= t of a
>=C2=A0 failed message, which in turn may contain personally identifiabl= e
>=C2=A0 information, which should be considered when decoding whether or= not to
>=C2=A0 generate such reports.

Ship it.

With one minor correction, I a= gree. The minor correction is in the last sentence: s/decoding/deciding/

--Kurt=C2=A0
--00000000000003702d05b72730f9-- From nobody Wed Dec 23 12:06: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 F2AB63A0BFF for ; Wed, 23 Dec 2020 12:06:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.697 X-Spam-Level: X-Spam-Status: No, score=-0.697 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, 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 hp9vxr-IzmcZ for ; Wed, 23 Dec 2020 12:06:49 -0800 (PST) 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 7F85C3A0A97 for ; Wed, 23 Dec 2020 12:06:47 -0800 (PST) Received: by mail-vs1-xe2e.google.com with SMTP id e20so339918vsr.12 for ; Wed, 23 Dec 2020 12:06:47 -0800 (PST) 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=43DIcfr+H5h/Ox/YKedPGyo2H/ziryDv3IT9MZyHOIc=; b=sXwqgiZ96Ovc/dv8K7DsYooApt/8KhrBroMRCtqTwSSr5NBfkkog3wiFa40J5q6nRy 8g21z5MVBKqLkMLCJZOjfrSi/NjnTLmJgKiKa3Y7aFPHMBibmpD/HzACuS5rPsuwl97C PlN7AxdJdzI6byIQ+XkseM9i/ltnrGyLx66zOR8ZI2JrTz8MWIu3v3v3YqtbZxbwYeGm R6Qxsuw+GTv4aL5/5nm19ZIp1iy95uw5/i483bm2M/e67Rqs/aPmDDfTPWRW8j1lS2GM cVSXWVDtm65VdfLg9YP2mRSkJ544j08+5MtWHGuue6+hKjC8e7/rpva1l0yS7aCBAgEq 8pQA== 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=43DIcfr+H5h/Ox/YKedPGyo2H/ziryDv3IT9MZyHOIc=; b=kFFdYnnHNl99f0UXXIAZoeL15gD+WlEh3eStP5zAIg4X8woiwkGmmfYNBD1jmCt5EC DsNAj4Gsmx5pIY61OK5+az+oxmvv7UeQ4M7Ye+J8c1WhCqeWz8Vh5Vjc2mrNXCJvm66j jd5cDJSa7r1SVYb7LpXGvNne4f543NFHLw0Ay+LDshvt54Og7rRgkZuXxVE6HRv3+WyM xZd8i7asVJNro7Fu3TjVMrZPQh2Jh9WlM3Yq/B34+ZFU+vAZNPVcW/h3xC2Pkcxst1ku le7c1McblFmbsZsLeV0R//cB54Fv41fXuM/Jin6+IIz9130HpUvaw55xEJ2HrSsGROYX RZxg== X-Gm-Message-State: AOAM530yJBDA4Ijq2woYk4JratpXxr3KUJJAJGB/42llOybAGElMPWWH Pvb7rR/iWaXP67UUPMamvfuVhnyeHuOaTk1CbDs= X-Google-Smtp-Source: ABdhPJxfLOb9HNBM1ST8wt3F1rCeLWm+7pl24AWLLJarGdZGsRZh5hZ+to3Im35g+croLDsg8+beO2iiTx9dRBXmJ6U= X-Received: by 2002:a67:fb46:: with SMTP id e6mr20392205vsr.40.1608754006348; Wed, 23 Dec 2020 12:06:46 -0800 (PST) MIME-Version: 1.0 References: <20201218023900.E73B82ACBB2B@ary.qy> <4a43ffaa-3987-c892-cce7-56f18888cdf5@tana.it> <39125012-e356-d62d-36fd-a7ff25a9f59f@taugh.com> <6bba023-d3d9-63a5-8441-11dac9a05e28@taugh.com> <74051a64-871a-db72-b5d9-1be374e23015@tana.it> <3034face-b6fc-0ce2-fa1b-f59210bd6f5b@tana.it> <46339b38-3b24-bcb7-5e73-8a97038ed69@taugh.com> <3997c81d-3b30-0823-a752-fb1d60a44593@tana.it> <74a5c37-19a6-6f6f-a51d-6e5cca5b29e8@taugh.com> <01RTICXKLL3E0085YQ@mauve.mrochek.com> In-Reply-To: From: "Murray S. Kucherawy" Date: Wed, 23 Dec 2020 12:06:33 -0800 Message-ID: To: John R Levine Cc: Ned Freed , IETF DMARC WG Content-Type: multipart/alternative; boundary="00000000000014567205b7273bf7" Archived-At: Subject: Re: [dmarc-ietf] Ticket #55 - Clarify legal and privacy implications of failure reports X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Dec 2020 20:06:57 -0000 --00000000000014567205b7273bf7 Content-Type: text/plain; charset="UTF-8" Hatless: On Wed, Dec 23, 2020 at 10:10 AM John R Levine wrote: > On Wed, 23 Dec 2020, Ned Freed wrote: > > Failure reports provide detailed information about the failure of a > single > > message or a group of similar messages failing for the same reason. They > > are meant to aid in cases where a domain owner is unable to detect why > > failures reported in aggregate form did occur. It is important to note > > these reports can contain either the header or the entire content of a > > failed message, which in turn may contain personally identifiable > > information, which should be considered when decoding whether or not to > > generate such reports. > > Ship it. > Modulo a couple of tweaks (below), I agree. Failing that, I have another proposal to consider that might aid us in shipping a standards track DMARC sooner: Remove any and all mention of failure reports, and do all that in a later add-on document as was done with RFC 6651. Tweaks: * s/whether or not/whether/ * s/decoding/deciding/ -MSK --00000000000014567205b7273bf7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hatless:

=
On Wed, Dec 23, 2020 at 10:10 AM John R Levine <johnl@taugh.com> wrote:
On We= d, 23 Dec 2020, Ned Freed wrote:
>=C2=A0 Failure reports provide detailed information about the failure o= f a single
>=C2=A0 message or a group of similar messages failing for the same reas= on. They
>=C2=A0 are meant to aid in cases where a domain owner is unable to dete= ct why
>=C2=A0 failures reported in aggregate form did occur. It is important t= o note
>=C2=A0 these reports can contain either the header or the entire conten= t of a
>=C2=A0 failed message, which in turn may contain personally identifiabl= e
>=C2=A0 information, which should be considered when decoding whether or= not to
>=C2=A0 generate such reports.

Ship it.

Modulo a couple of tweaks (bel= ow), I agree.

Failing that, I have another proposa= l to consider that might aid us in shipping a standards track DMARC sooner:= Remove any and all mention of failure reports, and do all that in a later = add-on document as was done with RFC 6651.

Twe= aks:

* s/whether or not/whether/
* s/decoding/d= eciding/

-MSK
--00000000000014567205b7273bf7-- From nobody Wed Dec 23 12:08: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 007243A09CD for ; Wed, 23 Dec 2020 12:08:36 -0800 (PST) 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 (2048-bit key) header.d=iecc.com header.b=eddU1Cl1; dkim=pass (2048-bit key) header.d=taugh.com header.b=Qsdx/zW5 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UUpFfcNURnLP for ; Wed, 23 Dec 2020 12:08:34 -0800 (PST) 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 AE9FE3A0994 for ; Wed, 23 Dec 2020 12:08:33 -0800 (PST) Received: (qmail 43346 invoked from network); 23 Dec 2020 20:08:30 -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=a94e.5fe3a3be.k2012; i=johnl-iecc.com@submit.iecc.com; bh=SUiYzxmBfEP9ORO1cZq6n/J8oFpLYE9ySY2AxBV2rwI=; b=eddU1Cl1TumwdyLGlc7Hr2Wu6/4IYMUUrNmosdgS4gbbqyQL6TWJh8y30KysBKmwCv2KAI/QwMSfyPANbnD+5Gtm3vV5zvUg5IfnG/Uf0OO5tBdLtBFRxzJrP7JsZARNzBhQrqIjqRm6JwI67pRpRdimHvSqjWr9N5+Qh7jArFRIUHHi+GvSoyP5RYbyZONFEB1shaZmbETxJ4ZTErkatlb1AvgbQbFlj/E20BKCzHGPHgSgr1aALJVNKfUAS/jyckp5aUtZPjc6uKKReKhd+RoSxrJqhXcE5AyC8khdfd5txMs/iUkaX7q5yHhMumOAPLW6p8FluVWbMC5CBAV6bg== 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=a94e.5fe3a3be.k2012; olt=johnl-iecc.com@submit.iecc.com; bh=SUiYzxmBfEP9ORO1cZq6n/J8oFpLYE9ySY2AxBV2rwI=; b=Qsdx/zW5WKNZNbn5w8AltThMqCnPN4lQrYML8geI4W4dsW8cx0S4hobb+Am7KwV14FBIDTLptlJ4UgV2kYnFdQZP5nW15TnCVaDXRvTNTiQaWn4QltmGj+8gqH6xHq5HnEubIzmb+WdEjSuKjZIcBtrzM5ubdca1WeuPLHRYHM5BYeQrx6nLAvP6ASY1ys8Hs1Kpfb845zIoq6i8Nj7Ig7w+uAZSOMhQlA4SHY6MKGn1lcg5GSRAG5kGE4hC12OfbI7z/vc3a2NWEHDVUSX9wfwhwKfybM2igGQZFJW0d1rofNQiLaHZJ5kEtm7N84/UjrvbFD7NQJbtj6f1kxQFpw== 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; 23 Dec 2020 20:08:30 -0000 Date: 23 Dec 2020 15:08:30 -0500 Message-ID: From: "John R Levine" To: "Murray S. Kucherawy" , "John R Levine" Cc: "Ned Freed" , "IETF DMARC WG" In-Reply-To: References: <20201218023900.E73B82ACBB2B@ary.qy> <4a43ffaa-3987-c892-cce7-56f18888cdf5@tana.it> <39125012-e356-d62d-36fd-a7ff25a9f59f@taugh.com> <6bba023-d3d9-63a5-8441-11dac9a05e28@taugh.com> <74051a64-871a-db72-b5d9-1be374e23015@tana.it> <3034face-b6fc-0ce2-fa1b-f59210bd6f5b@tana.it> <46339b38-3b24-bcb7-5e73-8a97038ed69@taugh.com> <3997c81d-3b30-0823-a752-fb1d60a44593@tana.it> <74a5c37-19a6-6f6f-a51d-6e5cca5b29e8@taugh.com> <01RTICXKLL3E0085YQ@mauve.mrochek.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [dmarc-ietf] Ticket #55 - Clarify legal and privacy implications of failure reports X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Dec 2020 20:08:36 -0000 > Modulo a couple of tweaks (below), I agree. > Tweaks: > > * s/whether or not/whether/ > * s/decoding/deciding/ Sure. Now ship it? > Failing that, I have another proposal to consider that might aid us in > shipping a standards track DMARC sooner: Remove any and all mention of > failure reports, and do all that in a later add-on document as was done > with RFC 6651. Given how marginal failure reports have turned out to be, that doesn't seem like a great use of our time. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From nobody Wed Dec 23 12:19: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 2217F3A0A0B for ; Wed, 23 Dec 2020 12:19:00 -0800 (PST) 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 PceHc6v1lqk3 for ; Wed, 23 Dec 2020 12:18:58 -0800 (PST) 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 85B9E3A09CD for ; Wed, 23 Dec 2020 12:18:58 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01RTIJD8ACCG00BQ3A@mauve.mrochek.com> for dmarc@ietf.org; Wed, 23 Dec 2020 12:13:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mrochek.com; s=201712; t=1608754435; bh=sx6GB16Zb6bH54P+UfO0Hh95XC+Obw+Afw2NntK+SVc=; h=From:Cc:Date:Subject:In-reply-to:References:To:From; b=YvDhy/JsVwCCzh5C7vDqNsxEksccNzqPpPl4d1ZhJzUYjr/+hsq8xNJ3ws7RRDJtg m46T+VC9WFE3XMZtDNNSKtxh7FJqLjuE1qcakqU3Z+Fxlz37TZCIKWw0ytmzRCvpPZ xRU/5xBPClt/WGVkxpttMNpLOltO2BdfhpWVN2ZQ= MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=US-ASCII Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01RTICDLNOW000CBED@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for dmarc@ietf.org; Wed, 23 Dec 2020 12:13:51 -0800 (PST) From: ned+dmarc@mrochek.com Cc: John R Levine , Ned Freed , IETF DMARC WG Message-id: <01RTIJD56D0600CBED@mauve.mrochek.com> Date: Wed, 23 Dec 2020 12:13:09 -0800 (PST) In-reply-to: "Your message dated Wed, 23 Dec 2020 12:03:28 -0800" References: <20201218023900.E73B82ACBB2B@ary.qy> <4a43ffaa-3987-c892-cce7-56f18888cdf5@tana.it> <39125012-e356-d62d-36fd-a7ff25a9f59f@taugh.com> <6bba023-d3d9-63a5-8441-11dac9a05e28@taugh.com> <74051a64-871a-db72-b5d9-1be374e23015@tana.it> <3034face-b6fc-0ce2-fa1b-f59210bd6f5b@tana.it> <46339b38-3b24-bcb7-5e73-8a97038ed69@taugh.com> <3997c81d-3b30-0823-a752-fb1d60a44593@tana.it> <74a5c37-19a6-6f6f-a51d-6e5cca5b29e8@taugh.com> <01RTICXKLL3E0085YQ@mauve.mrochek.com> To: "Kurt Andersen (b)" Archived-At: Subject: Re: [dmarc-ietf] Ticket #55 - Clarify legal and privacy implications of failure reports X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Dec 2020 20:19:00 -0000 > On Wed, Dec 23, 2020 at 10:10 AM John R Levine wrote: > > On Wed, 23 Dec 2020, Ned Freed wrote: > > > Failure reports provide detailed information about the failure of a > > single > > > message or a group of similar messages failing for the same reason. They > > > are meant to aid in cases where a domain owner is unable to detect why > > > failures reported in aggregate form did occur. It is important to note > > > these reports can contain either the header or the entire content of a > > > failed message, which in turn may contain personally identifiable > > > information, which should be considered when decoding whether or not to > > > generate such reports. > > > > Ship it. > > > With one minor correction, I agree. The minor correction is in the last > sentence: s/decoding/deciding/ Yes, sorry about that. Ned > --Kurt From nobody Wed Dec 23 13:51: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 ADB0B3A0E6D for ; Wed, 23 Dec 2020 13:51:56 -0800 (PST) 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=[BAYES_20=-0.001, 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 jiJtwjDaAyxU for ; Wed, 23 Dec 2020 13:51:55 -0800 (PST) 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 4A60E3A0E6C for ; Wed, 23 Dec 2020 13:51:55 -0800 (PST) Received: by mail-vs1-xe33.google.com with SMTP id b23so479265vsp.9 for ; Wed, 23 Dec 2020 13:51:55 -0800 (PST) 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=yh5JOp2xG6NBUFd/MGV/sRi+CHXKij+vlBjtLUooDvw=; b=VZG3I8hC8wRBfDHPc9mGI3vtb8/z4RlEz8osQISY4hxaL07XdGlUSZhjHg3AshtD37 fFUE6oHd+fGsDIs2yCrJVTQCTEwe5c1TR77Ld0u/sPMFD+Gg28fl0tfCOOUNJsk5wyk1 vuWcqU5cGfJTTBwTBdfGQE/bfu+bk7xbgljEZrwwpau+pkLKRXsISF6Y3ucLc/u1Ya0m hh22oX5yjv16eVm3DnN5tPYsZFwlIY06QibRk+nrQM+0cVUCDftopPgcK/0rkpSsTIpB BOFG2yeIjAZ9eKuFpRlHn6H8NpKwH14RuP9l1aVittIJXwLzKGeT54VXU+OXwWOoYt3B rg3A== 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=yh5JOp2xG6NBUFd/MGV/sRi+CHXKij+vlBjtLUooDvw=; b=dEZqmALIPMUMpw2PDPZbkePeLZYXNadnF1m5LkraPYG+7UfWiKafd752GxgrQyk0Ww gtzWLGiw/JGBbokAQ9NaLnvjWtdbgvNqok3LjS8tVKa4ybFcaGhzfv+GM0fzB25xAVpk 5fibGTXPnoOT7LyqOv9MmBJucJYgseGwj67pdVL2Lbs3oEFVdbTQWwoCA01DAhnsS/Ul jV6FvqwZf74A8xClu/Di8hthRwSsQNFPlozugigE+FQq+T+22qI+o78aDgaA1BDnNTfY ld/MopYHboQXf6Prd91ukU5yfPJfl3DZWrjAGs2+Ky306hgpCZeglCxwbdXGeq/rY14o Nu+g== X-Gm-Message-State: AOAM530H/67PaFfA4i1HSnvT/k5NJJFPMSxos1FPJdq3jbhZbV0CETNL olJbRljN62rs0oAYlkjQ7VNlDPHfk4r0S/4zLG8= X-Google-Smtp-Source: ABdhPJyuASbRaqSXfdFaaZSP2czFWJ24jQ8EhBiFs0YJxIJvAQ9G/4L5S8TlTeFKsMRyxaYN7encLV8V1mG1OMUY4ms= X-Received: by 2002:a67:f14f:: with SMTP id t15mr20583375vsm.0.1608760314356; Wed, 23 Dec 2020 13:51:54 -0800 (PST) MIME-Version: 1.0 References: <20201218023900.E73B82ACBB2B@ary.qy> <4a43ffaa-3987-c892-cce7-56f18888cdf5@tana.it> <39125012-e356-d62d-36fd-a7ff25a9f59f@taugh.com> <6bba023-d3d9-63a5-8441-11dac9a05e28@taugh.com> <74051a64-871a-db72-b5d9-1be374e23015@tana.it> <3034face-b6fc-0ce2-fa1b-f59210bd6f5b@tana.it> <46339b38-3b24-bcb7-5e73-8a97038ed69@taugh.com> <3997c81d-3b30-0823-a752-fb1d60a44593@tana.it> <74a5c37-19a6-6f6f-a51d-6e5cca5b29e8@taugh.com> <01RTICXKLL3E0085YQ@mauve.mrochek.com> In-Reply-To: From: "Murray S. Kucherawy" Date: Wed, 23 Dec 2020 13:51:41 -0800 Message-ID: To: John R Levine Cc: Ned Freed , IETF DMARC WG Content-Type: multipart/alternative; boundary="00000000000010e64105b728b36d" Archived-At: Subject: Re: [dmarc-ietf] Ticket #55 - Clarify legal and privacy implications of failure reports X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Dec 2020 21:51:57 -0000 --00000000000010e64105b728b36d Content-Type: text/plain; charset="UTF-8" On Wed, Dec 23, 2020 at 12:08 PM John R Levine wrote: > > Failing that, I have another proposal to consider that might aid us in > > shipping a standards track DMARC sooner: Remove any and all mention of > > failure reports, and do all that in a later add-on document as was done > > with RFC 6651. > > Given how marginal failure reports have turned out to be, that doesn't > seem like a great use of our time. > Well the "Remove" part was the key to getting us unstuck if this turns out to be a pain point, if they are indeed marginal and seldom used. So stick a "maybe" before "do". -MSK --00000000000010e64105b728b36d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Dec 23, 2020 at 12:08 PM John R L= evine <johnl@taugh.com> wrote:=
> Failing that, I have another proposal to consider that mig= ht aid us in
> shipping a standards track DMARC sooner: Remove any and all mention of=
> failure reports, and do all that in a later add-on document as was don= e
> with RFC 6651.

Given how marginal failure reports have turned out to be, that doesn't =
seem like a great use of our time.

Well= the "Remove" part was the key to getting us unstuck if this turn= s out to be a pain point, if they are indeed marginal and seldom used.=C2= =A0 So stick a "maybe" before "do".

-MSK
--00000000000010e64105b728b36d-- From nobody Wed Dec 23 16:34: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 68F3D3A08B0 for ; Wed, 23 Dec 2020 16:34:39 -0800 (PST) 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 QEUthnpSyaEF for ; Wed, 23 Dec 2020 16:34:38 -0800 (PST) Received: from mail-qt1-x835.google.com (mail-qt1-x835.google.com [IPv6:2607:f8b0:4864:20::835]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4DBCE3A0827 for ; Wed, 23 Dec 2020 16:34:37 -0800 (PST) Received: by mail-qt1-x835.google.com with SMTP id z20so618660qtq.3 for ; Wed, 23 Dec 2020 16:34:37 -0800 (PST) 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=8i4SzhCTleFXhHJKoB3yH8IcR1UBf6VixSRw3VDcBPA=; b=jVDx82O/YGT9u6TNYK1+t2s8QnkTf6eoE82VExtE7RiNstZiUoc6Xy3f/6my6Azc3E KtWj+V60AZr8J9LNkHvacSERDTdQwZKow3keyHkFZzpPyKuQWfWpl3UCAoD+re5+lYVV T+2zEdw52JH9+w+hG40zvlZWB0eKDHjwjJYkd8sPDp3bYaTXOXyf5GxQu3doTTm9ZYTb ZNPO+AEggRnQZXBvIMMu5FzB6WJ1FWQ6aZfWuuoEj0kBFpHGHBZvGZUOkowEsmlS4X8Q udCkUijyN1coTfAhVxE5nJfH29ShjTuxzt9C72dTrGgdUE3BQ4xAcMMGhFNHlwOz0Ak7 vqeA== 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=8i4SzhCTleFXhHJKoB3yH8IcR1UBf6VixSRw3VDcBPA=; b=B10KngZeNHSOYGec0vT+QmVPHLc/JAMh3ZSbs93cCUyu+eTAY+P3ruy0DJOiTJ75iS 5hpkyGRgm6dx9b8adlJSV9hQRzGWNnSxMp9KRYA3Di565vIAy9Ky8KbGQ8lTHB/d/0Yx FxcJf1D1n7i71ONAoEE3V7K1SJfYhs6Z1ODXTGTmM46vqMj9DyMLQM0gSxq8RjPqR2+w qas15Scmt8v2Pw3lG1d2Wna1Eicae5XYquQHfytb3J4ksrKVt0bg50/BHlm35CKFMtKP ZzPJhIFcVAhlGLqFspCIsrpETew28t84qLPXOaeiSh35g9z2kfdWDg0GV3qWlzXiokrC lsQw== X-Gm-Message-State: AOAM530N2LyzzESY7C8iVykcPQO4K1cWaFsMnIV6NwnrnUTjSGb5EFng WuTlkm5yhkpyixqYJ0604U2HZu8R46T5WkuxA/M= X-Google-Smtp-Source: ABdhPJxBeAtaGAHTQLlWs4fjJtWugeEbqL90NsoeYI3zIfY/CR+kQY0X8LonAX8z47lWPhXKz2acmBuEYOH2wKoxiKk= X-Received: by 2002:ac8:5c05:: with SMTP id i5mr27797795qti.34.1608770076494; Wed, 23 Dec 2020 16:34:36 -0800 (PST) MIME-Version: 1.0 References: <20201218023900.E73B82ACBB2B@ary.qy> <4a43ffaa-3987-c892-cce7-56f18888cdf5@tana.it> <39125012-e356-d62d-36fd-a7ff25a9f59f@taugh.com> <6bba023-d3d9-63a5-8441-11dac9a05e28@taugh.com> <74051a64-871a-db72-b5d9-1be374e23015@tana.it> <3034face-b6fc-0ce2-fa1b-f59210bd6f5b@tana.it> <46339b38-3b24-bcb7-5e73-8a97038ed69@taugh.com> <3997c81d-3b30-0823-a752-fb1d60a44593@tana.it> <74a5c37-19a6-6f6f-a51d-6e5cca5b29e8@taugh.com> <01RTICXKLL3E0085YQ@mauve.mrochek.com> In-Reply-To: From: Dotzero Date: Wed, 23 Dec 2020 19:34:26 -0500 Message-ID: To: "Murray S. Kucherawy" Cc: John R Levine , IETF DMARC WG , Ned Freed Content-Type: multipart/alternative; boundary="000000000000ef4e4105b72af8d5" Archived-At: Subject: Re: [dmarc-ietf] Ticket #55 - Clarify legal and privacy implications of failure reports X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Dec 2020 00:34:39 -0000 --000000000000ef4e4105b72af8d5 Content-Type: text/plain; charset="UTF-8" On Wed, Dec 23, 2020 at 4:52 PM Murray S. Kucherawy wrote: > On Wed, Dec 23, 2020 at 12:08 PM John R Levine wrote: > >> > Failing that, I have another proposal to consider that might aid us in >> > shipping a standards track DMARC sooner: Remove any and all mention of >> > failure reports, and do all that in a later add-on document as was done >> > with RFC 6651. >> >> Given how marginal failure reports have turned out to be, that doesn't >> seem like a great use of our time. >> > > Well the "Remove" part was the key to getting us unstuck if this turns out > to be a pain point, if they are indeed marginal and seldom used. So stick > a "maybe" before "do". > > -MSK > Based on my experience, I disagree that failure reports are marginal and seldom used. It's kind of like an iceberg, mostly below the surface. Seeing as most of the action is (currently) between contracted parties, it would be nice to hear some of the intermediaries such as Agari, ValiMail, Dmarcian and ? chime in. Perhaps some of the large mailbox providers could chime in on number of domains they are sending failure reports for. If individual companies providing numbers are a problem, perhaps M3AAWG could provide combined numbers from a number of mailbox providers/receivers. Michael Hammer --000000000000ef4e4105b72af8d5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Dec 23, 2020 at 4:52 PM Murra= y S. Kucherawy <superuser@gmail.c= om> wrote:
On Wed, Dec 23, 2020 at 12:08 PM John R= Levine <johnl@taug= h.com> wrote:
> Failing that, I have another proposal= to consider that might aid us in
> shipping a standards track DMARC sooner: Remove any and all mention of=
> failure reports, and do all that in a later add-on document as was don= e
> with RFC 6651.

Given how marginal failure reports have turned out to be, that doesn't =
seem like a great use of our time.

Well= the "Remove" part was the key to getting us unstuck if this turn= s out to be a pain point, if they are indeed marginal and seldom used.=C2= =A0 So stick a "maybe" before "do".

-MSK

Based on m= y experience, I disagree that failure reports are marginal and seldom used.= It's kind of like an iceberg, mostly below the surface. Seeing as most= of the action is (currently) between contracted parties, it would be nice = to hear some of the intermediaries such as Agari, ValiMail, Dmarcian and ? = chime in. Perhaps some of the large mailbox providers could chime in on num= ber of domains they are sending failure reports for. If individual companie= s providing numbers are a problem, perhaps M3AAWG could provide combined nu= mbers from a number of mailbox providers/receivers.

Michael Hammer
--000000000000ef4e4105b72af8d5-- From nobody Wed Dec 23 18:11: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 E7C9F3A0BE9 for ; Wed, 23 Dec 2020 18:11:53 -0800 (PST) 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 (2048-bit key) header.d=iecc.com header.b=CE8TWhxC; dkim=pass (2048-bit key) header.d=taugh.com header.b=Vhz8HNIn Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RKzAwMP1HMMq for ; Wed, 23 Dec 2020 18:11:52 -0800 (PST) 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 B6BCF3A0BEB for ; Wed, 23 Dec 2020 18:11:51 -0800 (PST) Received: (qmail 78748 invoked from network); 24 Dec 2020 02:11: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=13398.5fe3f8e4.k2012; i=johnl-iecc.com@submit.iecc.com; bh=KvfJB/AuWdB4afygBz5UsVQOUvvEvWbz0MZUM1vog+k=; b=CE8TWhxCqYWXW5WekOfTwhizZ7zLvSmCCzOORkvM4/ybo9YaXd5k2s3tcW++2OJ4uV2F/O6AmQ3fVruPRIYkhCcAHlfUnBrCmDjJ1V3mtDbWRUmV3zReKYoATSMx/JZGUiBrPl9akXkpts8mG/hFyg/WdgdF1YE1Vj3P2pdvW9ME8C9A88LxaVO5SvDZetDSIlEEXN8GB04zsD93fBShQe4U3gALGk+ZXsV/6Eit+itKgIgwrYqMdcQ+BAo19UwWCtAScXnQB3VZ4eHhOn+jBo8/PhwaE+uvJCSdcFyoyida9FQCrxAwSA+6ozzj6gf/bs08BJoG4JnJ9LtuwfiyaA== 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=13398.5fe3f8e4.k2012; olt=johnl-iecc.com@submit.iecc.com; bh=KvfJB/AuWdB4afygBz5UsVQOUvvEvWbz0MZUM1vog+k=; b=Vhz8HNInTYeNu8LL86rfxJVb7BUEa/VBXDDaq0Y4Rr0+h4sgbQ1RRRbdTRVHVPws9WURjqgAQFgeOnw0/Kvez7UBec8CCqOpZhnSdRknowpXAwU3LW0q5it82JNgH9fMBT2WzDLBEaSipt1Fs5/Kv/sNA5rcAA8fgffjSIvFw6EO71cOPmCE/RErQ7IqOQ1NhEfXQpXK4YeZEJnO650aumlFVKP++9Ps7jsankZRLRuFeCaR/KE8EDP3KFddA48yBWccVk+8bWXlJ7s7tswViWVV+mWV+1K/93H8czYToHopKEo0fNcZZOgrLoT6hUiWoOgFxc+bfRY/T0KjFWTHCA== 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; 24 Dec 2020 02:11:47 -0000 Date: 23 Dec 2020 21:11:47 -0500 Message-ID: From: "John R Levine" To: "Dotzero" Cc: "IETF DMARC WG" In-Reply-To: References: <20201218023900.E73B82ACBB2B@ary.qy> <6bba023-d3d9-63a5-8441-11dac9a05e28@taugh.com> <74051a64-871a-db72-b5d9-1be374e23015@tana.it> <3034face-b6fc-0ce2-fa1b-f59210bd6f5b@tana.it> <46339b38-3b24-bcb7-5e73-8a97038ed69@taugh.com> <3997c81d-3b30-0823-a752-fb1d60a44593@tana.it> <74a5c37-19a6-6f6f-a51d-6e5cca5b29e8@taugh.com> <01RTICXKLL3E0085YQ@mauve.mrochek.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [dmarc-ietf] Ticket #55 - Clarify legal and privacy implications of failure reports X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Dec 2020 02:11:54 -0000 On Wed, 23 Dec 2020, Dotzero wrote: > Based on my experience, I disagree that failure reports are marginal and > seldom used. It's kind of like an iceberg, mostly below the surface. ... Seems to me that if we splice in Ned's tweaked privacy language, we're done. I don't see any reason to change the technical spec. People will send what they send, and it's become clear that we have nothing useful to say about what one might redact. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From nobody Wed Dec 23 18:39: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 3A7A23A0E78 for ; Wed, 23 Dec 2020 18:39:16 -0800 (PST) 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 Pp1rCSrEFMLx for ; Wed, 23 Dec 2020 18:39:14 -0800 (PST) Received: from mail-ot1-x329.google.com (mail-ot1-x329.google.com [IPv6:2607:f8b0:4864:20::329]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2A903A0E7A for ; Wed, 23 Dec 2020 18:39:14 -0800 (PST) Received: by mail-ot1-x329.google.com with SMTP id d8so804633otq.6 for ; Wed, 23 Dec 2020 18:39:14 -0800 (PST) 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=xKwECr5/eqA2MXJI46lxHq6n3hXlfosSS0sFQp1ZY1E=; b=r+1PtsZBthj8EUKyv1TfB/vKdvd3qwqXmamfRpKJEKMDNlotfqKHgeVrUOZOIWspGI FZEfMOmEQNUYjpTLhiVeKbKlThDpjbaXp/jTeeJiTSNFFX5xrZ7e6DP8KXHEBv9KDcfx ywIxhyMr46H1V4MzvE7j+NVsOv2/uyfmsUQnC99eAwMaEnMGVn1JHij7wjFuJ5/zyGiB /u15oaP6XIh+paAxh4TcYoDPRF5axS07UIcYktrdsGk7zwIzttxxkYST7nXcc27eVVLZ c+vz/IaVobNu2hAJoxTY/I0gObl2xCXB4c1t7HXnVCJeRn7Dnd/OrFtcwmATXaCjrCN6 pXMw== 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=xKwECr5/eqA2MXJI46lxHq6n3hXlfosSS0sFQp1ZY1E=; b=TtBl23O8cRI4C8NQiJnD/rxHuKETGYfUyzvJ0caHqYIi2UIxoRgrPog5VzpKB+pkOy m5OpCK5WYorxjtRFfhxtOwYLa3Cff7qsK0Qjq71t0+uQcnu2mwwZoNktTpiyk7VN0cMX tAEpLbZwg9MabCFhSd7doimClXeKvRSV0hKwFj8djgNFaY7uC6OKf7GG/ib7MS6RvbT1 ZPMFq2M1n9r8Ap9n+OcREe/g06Z+Svo6e9/kaf8nLNH2WDVDEBp/jOPSzTcevtXnSCJ8 jcYLFBTg43LZ/6lC/ld9sps32XfTyPEVyyNx2R1Ov7hQc2z7SYeBR1QgAWpkZZGXsKED tSew== X-Gm-Message-State: AOAM532DjBtTGyLo5fqbwjr+qljOmRhBsTOqRNCpw8FQGV0HkIrXKiq6 nkWwsT06QQIOzVUWUb+Wk1+/zHCbVZ0A8nn0GG4= X-Google-Smtp-Source: ABdhPJz+KLrkA/0+w9Hf3P5WH7hNxbUZFyFGB2E/oFFldC0w7UzlvLdOHBXgqo0gH9Hw3fVN2oEohLXZbzHxmU/hi5g= X-Received: by 2002:a9d:3ef6:: with SMTP id b109mr21730108otc.288.1608777553965; Wed, 23 Dec 2020 18:39:13 -0800 (PST) MIME-Version: 1.0 References: <20201218023900.E73B82ACBB2B@ary.qy> <6bba023-d3d9-63a5-8441-11dac9a05e28@taugh.com> <74051a64-871a-db72-b5d9-1be374e23015@tana.it> <3034face-b6fc-0ce2-fa1b-f59210bd6f5b@tana.it> <46339b38-3b24-bcb7-5e73-8a97038ed69@taugh.com> <3997c81d-3b30-0823-a752-fb1d60a44593@tana.it> <74a5c37-19a6-6f6f-a51d-6e5cca5b29e8@taugh.com> <01RTICXKLL3E0085YQ@mauve.mrochek.com> In-Reply-To: From: Tim Wicinski Date: Wed, 23 Dec 2020 21:39:03 -0500 Message-ID: To: John R Levine Cc: Dotzero , IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000a0771305b72cb6e8" Archived-At: Subject: Re: [dmarc-ietf] Ticket #55 - Clarify legal and privacy implications of failure reports X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Dec 2020 02:39:16 -0000 --000000000000a0771305b72cb6e8 Content-Type: text/plain; charset="UTF-8" I Believe I agree with the current version, but can someone post what we think is the final text? tim On Wed, Dec 23, 2020 at 9:12 PM John R Levine wrote: > On Wed, 23 Dec 2020, Dotzero wrote: > > Based on my experience, I disagree that failure reports are marginal and > > seldom used. It's kind of like an iceberg, mostly below the surface. ... > > Seems to me that if we splice in Ned's tweaked privacy language, we're > done. I don't see any reason to change the technical spec. People will > send what they send, and it's become clear that we have nothing useful to > say about what one might redact. > > Regards, > John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY > Please consider the environment before reading this e-mail. https://jl.ly > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > --000000000000a0771305b72cb6e8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I Believe I agree with the current version, but can someone post what we= think is the final text?=C2=A0

tim


On Wed, Dec 23, 2020 at 9:12 PM John R Levine <<= a href=3D"mailto:johnl@taugh.com">johnl@taugh.com> wrote:
<= 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">On Wed, 23 Dec 2020, Dotze= ro wrote:
> Based on my experience, I disagree that failure reports are marginal a= nd
> seldom used. It's kind of like an iceberg, mostly below the surfac= e. ...

Seems to me that if we splice in Ned's tweaked privacy language, we'= ;re
done.=C2=A0 I don't see any reason to change the technical spec.=C2=A0 = People will
send what they send, and it's become clear that we have nothing useful = to
say about what one might redact.

Regards,
John Levine, johnl@tau= gh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
--000000000000a0771305b72cb6e8-- From nobody Thu Dec 24 01: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 DC32F3A1123 for ; Thu, 24 Dec 2020 01:35:15 -0800 (PST) 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, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 iSv2DSmYyk6i for ; Thu, 24 Dec 2020 01:35:14 -0800 (PST) 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 1BC7A3A111A for ; Thu, 24 Dec 2020 01:35:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1608802510; bh=OdnMY47ccJk0H4bREMbQndofKIB6SKL8AayJzyNUbLk=; l=496; h=To:References:From:Date:In-Reply-To; b=Cq5THkw6sEW+QJ0Jlr8TWgyTllX2+n0twnobtLEna6yt5olMf5wtV978XpFdSoKI8 zZnju2zZzZ3UnaLchMS1FCqW8tr0pttw/T2GnGrKB3MKhML837dIJbzGVYdQ/LNx5u GPIXQvcElkmCJTHmGFHZCsQ6FVQmdqzrHzehCbK9Afw6K0gAwf3CYCrFNoBHt Authentication-Results: tana.it; auth=pass (details omitted) Original-From: Alessandro Vesely 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.000000005FE460CE.00003451; Thu, 24 Dec 2020 10:35:10 +0100 To: Tim Wicinski , John R Levine , IETF DMARC WG , Dotzero References: <20201218023900.E73B82ACBB2B@ary.qy> <74051a64-871a-db72-b5d9-1be374e23015@tana.it> <3034face-b6fc-0ce2-fa1b-f59210bd6f5b@tana.it> <46339b38-3b24-bcb7-5e73-8a97038ed69@taugh.com> <3997c81d-3b30-0823-a752-fb1d60a44593@tana.it> <74a5c37-19a6-6f6f-a51d-6e5cca5b29e8@taugh.com> <01RTICXKLL3E0085YQ@mauve.mrochek.com> From: Alessandro Vesely Message-ID: Date: Thu, 24 Dec 2020 10:35:10 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Ticket #55 - Clarify legal and privacy implications of failure reports X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Dec 2020 09:35:16 -0000 On Thu 24/Dec/2020 03:39:03 +0100 Tim Wicinski wrote: > I Believe I agree with the current version, but can someone post what we think > is the final text? I posted it here: https://github.com/ietf-wg-dmarc/draft-ietf-dmarc-failure-reporting I don't think the text is final, though. Besides minor tweaks in the first paragraphs of Section 3, the whole discussion about external destinations has to be stroked and replaced with a reference to aggregate reporting. Best Ale -- From nobody Thu Dec 24 03:31: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 867353A11C4 for ; Thu, 24 Dec 2020 03:31:12 -0800 (PST) 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, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 cn3BGd2Yh93P for ; Thu, 24 Dec 2020 03:31:09 -0800 (PST) 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 11A403A11C2 for ; Thu, 24 Dec 2020 03:31:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1608809464; bh=aQUbUHAfcVGcCZAlTYU49CgNrg+JSmgPzPbUbWRO9b4=; l=2698; h=To:References:From:Date:In-Reply-To; b=AoaE0M7CvR7RA55yxEHhE189g7C3wq35vVPaOsV11JwxOcEGlUF58ADGXKwMx5Q2v eaEygMTvRBpKkwzMlX1J6OFLnFKitjehsdfGzL3j7vH8U7iTrRxvt4DjllHX2fNvCH 0/5XXb/XAxkevSfOVupznCLuVTZFM4fSIS9HHs+Kr96HBsto8w9MQrNTycs0m Authentication-Results: tana.it; auth=pass (details omitted) Original-From: Alessandro Vesely 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.000000005FE47BF8.00004008; Thu, 24 Dec 2020 12:31:04 +0100 To: dmarc@ietf.org References: From: Alessandro Vesely Message-ID: <4bd17210-afbd-3a26-66c2-7a540232b146@tana.it> Date: Thu, 24 Dec 2020 12:31:04 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Discussion - ARC/Extensible Reporting (Ticket #56) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 24 Dec 2020 11:31:13 -0000 On Mon 07/Dec/2020 23:17:16 +0100 Marc Bradshaw wrote: > > There is value in including these in one report, especially where the extended > property being reported on influences how DMARC is evaluated. I think I represent a meagre minority of people who reads individual DMARC reports. Most other people I heard of pour their reports into a database and then query the latter. For them, it is indifferent whether reports come in a single file or spread among multiple ones. > Using ARC as the example, when a p=reject policy was overridden by the receiver > because of an ARC evaluation, when that data is included in the report the > indirect mail flow can be clearly seen, which would not be the case if ARC were > included as a separate report. When I look at an aggregate record whose relaying IP is 4.31.198.44, SPF domain is ietf.org, and some DKIM signatures are also tagged ietf.org, it is clear to me that it is an indirect mail flow. Sometimes I get: local_policyarc=pass If I had a separated ARC file keyed on relaying IPs, I could have found ARC values in there and matched them against that row in the DMARC report. > This could be included in an element, or could be included directly > in the auth_results section of the report, based on an assumption that the > things being reported SHOULD have an authentication results entry in processed > mail. > > > ... > ... > (as defined in arc standard) > (as defined in foo standard) > Say you have: example.compass What would that mean? Perhaps that, according to example.com, the message did pass, but by what authentication method? An stanza in auth_results would have to be succinct. If there is more structured data, auth_results doesn't seem to be the right place to stuff it. I'd propose to first define what data ARC would report. How to report it comes after. > These would be defined in a registry with reference to each standard, and > parsers would ignore any sections they did not understand. I'd hope we'll come out with proper XML syntax, a namespace like, say, urn:ietf:params:xml:ns:dmarc:aggregate:1.1 or some such, and a proper schema location. I think the element of has to become mandatory, which makes a difference between reports using a pre-standardization schema and upgraded ones. Then, an XML schema can import other schemata, but dependencies and increased complexity will have to be weighted in. Best Ale -- From nobody Thu Dec 24 10: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 8B3563A137E for ; Thu, 24 Dec 2020 10:55:12 -0800 (PST) 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 (2048-bit key) header.d=iecc.com header.b=ZbDfnRYJ; dkim=pass (2048-bit key) header.d=taugh.com header.b=JKkLe4rC Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NpQRF7c1NHxj for ; Thu, 24 Dec 2020 10:55:11 -0800 (PST) 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 CB9503A07F0 for ; Thu, 24 Dec 2020 10:55:10 -0800 (PST) Received: (qmail 80058 invoked from network); 24 Dec 2020 18:55:08 -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=138b8.5fe4e40c.k2012; i=johnl-iecc.com@submit.iecc.com; bh=5Wu06dzv8d9zIHwjCKbhvbtqF9W4HiFGq2wolIKlhRI=; b=ZbDfnRYJO2xgPpuIXeoExnpdxUPanRrUZhAMcnVrUc3lA2j+nUNasWrQRE25F1lDRKd1eIaMxNy0V9+6Yv0qY82EyBXcp+ydTlPVRPcCMqXyU35DZYtN0JZrnBCoXu5ySBWTQMleabgdZClLGHRSbtn7HDg6HexRLNDZAgtRlddKDt/Pv0LIZ0Qgjg9yJtOWvZNp+3UvYj2OpeK4lJIsBrofgI+q3cgdxna/MQe4a1UDzaNGT/GD0Pwz0VENvgzvY1UhSpJVrJbTICztycdw6Bhkd3hpEp+73Q1wQceNl/PyYBkhiggwEkAIH50YYZ2RNySrUBG9umEb1amNaQ9THA== 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=138b8.5fe4e40c.k2012; olt=johnl-iecc.com@submit.iecc.com; bh=5Wu06dzv8d9zIHwjCKbhvbtqF9W4HiFGq2wolIKlhRI=; b=JKkLe4rCH0AGvHZC6JkxtmXN97mCTWs4vC/f0dFf+pFhsk3q36Ppcif29JpffRynnSRmSPJIIzlUB97ZPDBW+H/74WItAOFCD6KOLADBUxJp8TUWRkBGFYLh9bgLOd/68gAazTLm5i2lO66fl7eegF3H7K1HzyY7TIC+7391znkN4Z3pKwrsH3uzWAOD0jUenpinjvni5e+EJEDRhDDRbqpYnpKY0Mqa/c4o/ItvPNLGb9qg4OzLkhRMO9ZwJItthOjLyhpylLW6AeSlMtZWbM0PgIpwfNtO+JoNjwuDXpsaB8kTnsoPjIuOS1f3eYwgB8etSCis76XtJPhIxRq4aQ== 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; 24 Dec 2020 18:55:07 -0000 Date: 24 Dec 2020 13:55:07 -0500 Message-ID: <8813331f-f5e4-faa5-c6d-11212fc25797@taugh.com> From: "John R Levine" To: "Alessandro Vesely" , "Tim Wicinski" , "IETF DMARC WG" In-Reply-To: References: <20201218023900.E73B82ACBB2B@ary.qy> <3034face-b6fc-0ce2-fa1b-f59210bd6f5b@tana.it> <46339b38-3b24-bcb7-5e73-8a97038ed69@taugh.com> <3997c81d-3b30-0823-a752-fb1d60a44593@tana.it> <74a5c37-19a6-6f6f-a51d-6e5cca5b29e8@taugh.com> <01RTICXKLL3E0085YQ@mauve.mrochek.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [dmarc-ietf] Ticket #55 - Clarify legal and privacy implications of failure reports X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Dec 2020 18:55:13 -0000 > On Thu 24/Dec/2020 03:39:03 +0100 Tim Wicinski wrote: >> I Believe I agree with the current version, but can someone post what we >> think is the final text? See below, with the two changes mentioned before and Mr Copy Edit's minor tightening up which I hope are not controversial. Ale said: > I posted it here: > https://github.com/ietf-wg-dmarc/draft-ietf-dmarc-failure-reporting Hold it. I don't recall that we agreed to break failure reports into a separate document. It makes more work and I see no agreement to change anything beyond the security paragraph. In particular, we have nothing to offer on what one might or might not redact. R's, Jobn Security considerations Failure reports provide detailed information about the failure of a single message or a group of similar messages failing for the same reason. They are meant to aid domain owners to detect why failures reported in aggregate form occured. It is important to note these reports can contain either the header or the entire content of a failed message, which in turn may contain personally identifiable information, which should be considered when deciding whether to generate such reports. From nobody Sat Dec 26 02:47: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 05F3C3A0FE7 for ; Sat, 26 Dec 2020 02:47:32 -0800 (PST) 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, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 NKuddeD13sBr for ; Sat, 26 Dec 2020 02:47:30 -0800 (PST) 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 265F33A0FE2 for ; Sat, 26 Dec 2020 02:47:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1608979646; bh=/TQZEe64pTxIv2xWu9cq7nNErDjoDtCKPbdnVbtZTIU=; l=2095; h=To:References:From:Date:In-Reply-To; b=Bv664h617YAbJOjheA/WznWnw6Ht/VMQ30a0Ydk7zavJvsLhtLwvsVbWN/WYWxY3v Y2HXYO0CSCnQN35cKmLQOOgOG/XuRhLiDq2LcE/MSqqineggXXs1AVTWyGqwcKO8EJ cXh+CxyAdW3CWY+rBKt8f9NT8daFglcR2gH3/0rkMHxLe8FAJTIUyYOCEBbL4 Authentication-Results: tana.it; auth=pass (details omitted) Original-From: Alessandro Vesely 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.000000005FE714BE.00003D28; Sat, 26 Dec 2020 11:47:26 +0100 To: John R Levine , Tim Wicinski , IETF DMARC WG References: <20201218023900.E73B82ACBB2B@ary.qy> <3034face-b6fc-0ce2-fa1b-f59210bd6f5b@tana.it> <46339b38-3b24-bcb7-5e73-8a97038ed69@taugh.com> <3997c81d-3b30-0823-a752-fb1d60a44593@tana.it> <74a5c37-19a6-6f6f-a51d-6e5cca5b29e8@taugh.com> <01RTICXKLL3E0085YQ@mauve.mrochek.com> <8813331f-f5e4-faa5-c6d-11212fc25797@taugh.com> From: Alessandro Vesely Message-ID: <5d150251-427c-5c44-a0c3-ad2e7f24b692@tana.it> Date: Sat, 26 Dec 2020 11:47:26 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: <8813331f-f5e4-faa5-c6d-11212fc25797@taugh.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] Ticket #55 - Clarify legal and privacy implications of failure reports X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Dec 2020 10:47:32 -0000 On Thu 24/Dec/2020 19:55:07 +0100 John R Levine wrote: >> On Thu 24/Dec/2020 03:39:03 +0100 Tim Wicinski wrote: >>> I Believe I agree with the current version, but can someone post what we >>> think is the final text? > > See below, with the two changes mentioned before and Mr Copy Edit's minor > tightening up which I hope are not controversial. > > Ale said: >> I posted it here: >> https://github.com/ietf-wg-dmarc/draft-ietf-dmarc-failure-reporting > > Hold it. I don't recall that we agreed to break failure reports into a separate > document. The fact that draft-ietf-dmarc-failure-reporting-00 exists on IETF datatracker seems to confirm WG consensus. But see also: https://mailarchive.ietf.org/arch/msg/dmarc/2DsSazvE9QxFjVSeg_mdNlRMETM > It makes more work and I see no agreement to change anything beyond the > security paragraph. In particular, we have nothing to offer on what one > might or might not redact. I still think it'd be a good idea to mention RFC 6590... Anyway, the change at hand arose from a ticket, as per Subject:. After a long discussion, the new paragraph was explicitly proposed for the Introduction of the separated document, where it is most effective. IMHO, Ned's wording —which you said to ship— is more comprehensive than the abbreviated version quoted below, hence preferable. Why did you change your mind? Best Ale > Security considerations > > Failure reports provide detailed information about the failure of a > single message or a group of similar messages failing for the same > reason. They are meant to aid domain owners to detect why failures > reported in aggregate form occurred. It is important to note these > reports can contain either the header or the entire content of a > failed message, which in turn may contain personally identifiable > information, which should be considered when deciding whether to > generate such reports. > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc From nobody Sat Dec 26 15:48: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 08E073A0BF8 for ; Sat, 26 Dec 2020 15:47:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, 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=mtcc.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 lAtKEy7Te0f5 for ; Sat, 26 Dec 2020 15:47:58 -0800 (PST) Received: from mail-pg1-x530.google.com (mail-pg1-x530.google.com [IPv6:2607:f8b0:4864:20::530]) (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 EAFE63A0BF7 for ; Sat, 26 Dec 2020 15:47:57 -0800 (PST) Received: by mail-pg1-x530.google.com with SMTP id n10so5137384pgl.10 for ; Sat, 26 Dec 2020 15:47:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mtcc.com; s=fluffulence; h=to:from:subject:message-id:date:user-agent:mime-version :content-transfer-encoding:content-language; bh=u8SC14bpaRCUtr7D5REGqhXsSCl/oF4LWgVsFgjzLlM=; b=DwjT1KbKbg1Mr8gmFxalxFOVhO+sgSQ0USyYIe8V5Wds1JbSUVrRnDPhw/FE/RLA33 RMcIQmaWkCz+IZuoBhctrZTem87rYfFY4S8Oqwsha5NGTnTT018mJEUvGHF+Y7pHaaEz uljoLJYWb2avvvkUz8ui+PuSbZTf4GWFfVpypIVLaJczaRVgX3LfkN1Gqy2bnin5cAKT F0o8nUg4qEF3mfDbOggYwtHGwYetDmlEjw4qXo4l3RbyA3BUsHHawkCwb7EZCLWuJw1L WFH7f5Y3qeWgNRMdaE/wPPTEfch2/IOVLAAvB3hFxwDtWef3+hDo3gyBs2/qDDVxjVqH yhww== 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-transfer-encoding:content-language; bh=u8SC14bpaRCUtr7D5REGqhXsSCl/oF4LWgVsFgjzLlM=; b=k86F8gN+brGu1qbz4x26nPM0MB7ARFm/Jmh4eaLRqQkLdZPuqAcoP8L0dw3WQMcRP3 oZpClvs6tdn8Dlq/HtsWfDDGU9wsio6HvcMF32g19f5APEEd/kp+YQv+pEtLt6o2Bq6m e1sBxZfdHRMLmbjIYllRtWRIrjehBORa+HXoNFugCh1ojm1+XFmiKOtanxKLlraR/0gv jgVkVI3yBliYFR0aKDUKxF8Tjv9Se2iUx6IZAfOikmQFwp0V7zbqddZ6rHEenw+1F/bX OFtCVx1KVSZQ/eyK0iNKzLyLEoS/dALjivd7x4Jx2qw9xkqIbZqnFNyzvSbQXK3E/RRc VuGw== X-Gm-Message-State: AOAM530+Imu9UgNYKQj1MDGLIgCfHpUAp7J0zYmnZCY0Nrk+9F+PNl6I D6eo6uzyvEtSrNyZwZQdU0LTZaqDBckLKg== X-Google-Smtp-Source: ABdhPJx+vrm93hpvaEQYPBeK9eZop7X26BTRh4CMVIxo9MCajQv2zZ7x4Z03jn9npAXGZrCj5SOUTA== X-Received: by 2002:a63:7904:: with SMTP id u4mr37474429pgc.41.1609026476742; Sat, 26 Dec 2020 15:47:56 -0800 (PST) Received: from mike-mac.lan ([107.182.37.0]) by smtp.gmail.com with ESMTPSA id e10sm29927134pgu.42.2020.12.26.15.47.55 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 26 Dec 2020 15:47:56 -0800 (PST) To: "dmarc@ietf.org" From: Michael Thomas Message-ID: <9f6782b1-e85b-1a9c-9151-98feff7e18ea@mtcc.com> Date: Sat, 26 Dec 2020 15:47:54 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.5.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: [dmarc-ietf] auth-res vs. dmarc X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Dec 2020 23:47:59 -0000 I installed this handy dandy t-bird dkim verifier extension which also allows you to just use the upstream auth-res.  After fixing a bug in it, I could see that it lists DMARC as a fail when DKIM failed, but SPF passed. The _dmarc record has p=none, so it seems really odd to call that a DMARC failure. Shouldn't it just be using the appropriate p= tag instead of "fail"? Is this left over from when Auth-res was mainly for dkim? Aside to John Levine: you had two messages to nanog back to back, one verified and one failed DKIM. I doesn't seem like nanog is doing any rewriting or anything so that is very strange. Maybe they are inadvertently rewriting in some situations that aren't obvious? Mike From nobody Sun Dec 27 03:00:13 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC5EE3A0475 for ; Sun, 27 Dec 2020 03:00:10 -0800 (PST) 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 LRjLWDinOy_I for ; Sun, 27 Dec 2020 03:00:06 -0800 (PST) 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 8C21D3A03F8 for ; Sun, 27 Dec 2020 03:00:06 -0800 (PST) Received: (qmail 90285 invoked by uid 100); 27 Dec 2020 11:00:05 -0000 Date: 27 Dec 2020 10:59:41 -0000 Message-ID: <20201227105941.90262.qmail@submit.iecc.com> From: "John Levine" To: dmarc@ietf.org Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Archived-At: Subject: [dmarc-ietf] Messages from the dmarc list for the week ending Sun Dec 27 06:00:04 2020 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Dec 2020 11:00:12 -0000 Count | Bytes | Who ------------+----------------+------- 17 (34.0%) | 98873 (25.5%) | Alessandro Vesely 11 (22.0%) | 59211 (15.3%) | John Levine 6 (12.0%) | 38088 ( 9.8%) | Michael Thomas 3 ( 6.0%) | 13012 ( 3.4%) | Benny Pedersen 2 ( 4.0%) | 39519 (10.2%) | Todd Herr 2 ( 4.0%) | 21730 ( 5.6%) | Dotzero 2 ( 4.0%) | 15149 ( 3.9%) | Murray S. Kucherawy 2 ( 4.0%) | 13156 ( 3.4%) | Kurt Andersen (b) 2 ( 4.0%) | 12770 ( 3.3%) | 1 ( 2.0%) | 34982 ( 9.0%) | Emil Gustafsson 1 ( 2.0%) | 33170 ( 8.5%) | Douglas Foster 1 ( 2.0%) | 8395 ( 2.2%) | Tim Wicinski From nobody Mon Dec 28 05:17:30 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92FF03A0AC8 for ; Mon, 28 Dec 2020 05:17:29 -0800 (PST) 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 O4pJS8FpZIHS for ; Mon, 28 Dec 2020 05:17:27 -0800 (PST) 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 9CD3C3A0AC4 for ; Mon, 28 Dec 2020 05:17:27 -0800 (PST) Received: by mail-qt1-x82c.google.com with SMTP id y15so6824884qtv.5 for ; Mon, 28 Dec 2020 05:17:27 -0800 (PST) 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=tdaCtwXsPoK9ci5wM9YKUs4Hl3Vll6s5TQMal1nCnnA=; b=VJcx2wd+838Ntw5XRuGk3FdbhrJTVe8raz5os1J4SlMKT2jx6arx6lV2Gm4RC5Fubj 2CMEjIWL4lMjR8U/0aGh9H/CfuY87W5NeI2RqPbDq2zui8v47cJX1bBUO+xRJ/qCOLTR CTNu8rPLfeRQTmkQT7YNY5bUyIHr6kWq+g9DUNC6pWz1AFhrcKj/dUl1Q9gon7q9zy/7 5JjPvsqJ8GYx4UAqHWhy1yNgfEFpatc8iNMG8Y8tmK9O92ePAAUAgS8HFVfnMNEAWsQB YbKUrG3sI3QAqD7eW1+GXBHuT3KTzZswVGAOboY/Vd51d7OoBywxiG9uJDJoSapKYIQ9 ngTQ== 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=tdaCtwXsPoK9ci5wM9YKUs4Hl3Vll6s5TQMal1nCnnA=; b=Jkh5B1OteZlwWRj7VCt5CUTX0eSMguWAbueei70nBnDKBR8sTMWa44pvR9gItO9H3j DdoDbLHhbaN/Zq/+YBTEmxfKvONWyOor4mFbult3WdAbEtOgU7uAqQXFXEh7Z5oDSinB fqiB7YO2/2PjqWxuX8x1+iS6PsUUHWil8kfHhO4X+ODe/gaTHWDAjA5wtBQffHmmmjgN dBrP6qaHzR161Nm3x0rF+hCniDwMXSBe/uEtSpnvctH6VWWdC9YTzNhyCYgW0QLdERyO 5fRcm5Fw41xAQX+dFhCmFUfpXY6zaokrTcfs66YIBgUPfAB617rigJo1m8CCqRpHokQ7 DWbg== X-Gm-Message-State: AOAM533b2nPeFNxfa4wPS9Ujxof2yABe3MGQIAhFAPc8Pfl0rK3DeHup LD9zBy1R1Eow1I9VZBDvdxsY7S8iGeYr2bKEkWi1PA== X-Google-Smtp-Source: ABdhPJxaEJkXsZa9Gbgz6UwSa5Klr1B2Tu3xO17m193aFO3L6VweCzPBhBtbfIwQEljjJbp539ZOvsTQD//FZzTGSac= X-Received: by 2002:a05:622a:14e:: with SMTP id v14mr44286119qtw.298.1609161444350; Mon, 28 Dec 2020 05:17:24 -0800 (PST) MIME-Version: 1.0 References: <9f6782b1-e85b-1a9c-9151-98feff7e18ea@mtcc.com> In-Reply-To: <9f6782b1-e85b-1a9c-9151-98feff7e18ea@mtcc.com> From: Todd Herr Date: Mon, 28 Dec 2020 08:17:08 -0500 Message-ID: To: Michael Thomas Cc: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="00000000000046f90b05b78618e8" Archived-At: Subject: Re: [dmarc-ietf] auth-res vs. dmarc X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Dec 2020 13:17:30 -0000 --00000000000046f90b05b78618e8 Content-Type: text/plain; charset="UTF-8" On Sat, Dec 26, 2020 at 6:48 PM Michael Thomas wrote: > > I installed this handy dandy t-bird dkim verifier extension which also > allows you to just use the upstream auth-res. After fixing a bug in it, > I could see that it lists DMARC as a fail when DKIM failed, but SPF > passed. The _dmarc record has p=none, so it seems really odd to call > that a DMARC failure. Shouldn't it just be using the appropriate p= tag > instead of "fail"? Is this left over from when Auth-res was mainly for > dkim? > > A DMARC pass verdict requires not only that SPF or DKIM pass, but also that the SPF or DKIM domain in question align with the DMARC (RFC5322.From) domain. A message such as the following: - Return-Path: - DKIM domain: b.org - From: bar@c.com Can get an SPF pass for a.net and have its DKIM signature validate, but still fail DMARC for c.com because neither a.net nor b.org align with c.com. Can you share the example auth-res header(s) in question along with the DMARC policy record(s) for the message(s)? -- *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. --00000000000046f90b05b78618e8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sat, Dec 26, 2020 at 6:48 PM Michael T= homas <mike@mtcc.com> wrote:
=

I installed this handy dandy t-bird dkim verifier extension which also
allows you to just use the upstream auth-res.=C2=A0 After fixing a bug in i= t,
I could see that it lists DMARC as a fail when DKIM failed, but SPF
passed. The _dmarc record has p=3Dnone, so it seems really odd to call
that a DMARC failure. Shouldn't it just be using the appropriate p=3D t= ag
instead of "fail"? Is this left over from when Auth-res was mainl= y for dkim?


A DMARC pass verdict requires not only= that SPF or DKIM pass, but also that the SPF or DKIM domain in question al= ign with the DMARC (RFC5322.From) domain. A message such as the following:<= /div>
Can get an SPF p= ass for a.net and have its DKIM signature vali= date, but still fail DMARC for c.com because n= either a.net nor b.or= g align with c.com.

Can you share the example auth-res header(s) in question along with the = DMARC policy record(s) for the message(s)?
=C2=A0
--

Todd Herr | Sr. Technical Program Manager
<= div style=3D"text-align:left">e:= todd.herr@valimail.com
p: 703.220.4153 <= /span>


This email and all data transmitted with it contains confidenti= al and/or proprietary information intended solely for the use of individual= (s) authorized to receive it. If you are not an intended and authorized rec= ipient you are hereby notified of any use, disclosure, copying or distribut= ion 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.

--00000000000046f90b05b78618e8-- From nobody Mon Dec 28 05:30: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 61DC23A0AF3 for ; Mon, 28 Dec 2020 05:30:07 -0800 (PST) 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 pwZG207FcDjY for ; Mon, 28 Dec 2020 05:30:05 -0800 (PST) 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 65BB43A0AEE for ; Mon, 28 Dec 2020 05:30:05 -0800 (PST) Received: by mail-qk1-x72a.google.com with SMTP id z11so8737128qkj.7 for ; Mon, 28 Dec 2020 05:30:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=xa41oyl/jhKQuIKjYwF47M6WoWqp6Gq0DLhoOg0xxQE=; b=LLCJaOpjWlPuVS6ZXIsXZkHx+9lZKhx5zFsnqlOTxch87PjQkqOSuMwV4V6etJaPZu ISfI0T8i2ETWXZuoiZQSuii4319rJ20UUOIBAxS6ngnpY0YVPi14eQ3w1b78XGNhL4ay qL+CQCT2wGRxkfYU47hOLtlJkjJ+wh3G+NZhOPLOFfqDs8t3qN5mg1neb8Se92hnNXl/ 6rNNJ3W3818GpdJkiqY3t+QwBYuK8kzycwKgSEv84Jz0LVx8Jq94CmJc1hDfR7q8MS8s e9ql882M72wvYPjS8hM2qImP/JGpnJRU0649Mon5be2NCDInQGOrpK+Az7J071s4IK2j zNcw== 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=xa41oyl/jhKQuIKjYwF47M6WoWqp6Gq0DLhoOg0xxQE=; b=fV8C0u45GnWgOaGcgAtzm+WIJIfAbU+lBjruzBT4BvnzcXpwTNjL7zSaq02ovwsArG Hp6kv1Xdu4JOXFw4C+Y80l61ooNvJRrf81KjAArJAbwnO4KxAChdPiQBpMjXmZ7angCU sDYQiSAVGx16KB9UhdCs5TEcvWJQVZInWmSkLmPoGNnGwLPG4BAYs+sUYgxHdD4Knc94 R9C/RUX7EGiQQseFoGpsJm3RBYWBlnbhb3MEy1ZMyuVktvyBxB8XjqNTj8UDKlGM8pqL A15Ql5Y6VyTrOkA9LaXZDMvcxdQ2Q9xXvQu1226F5wCLMIVGFx0bU1HULmaluFma7kfq Rwvw== X-Gm-Message-State: AOAM5336C/lyYEHcrXcD5xFl9v+qo4MQH9hl+z6WIJVycuVgkHSuEEa7 emfC+4yBRrnJFyQIeOn0Lg4nKCBotFLGUyJxLd7ns9q6jgA= X-Google-Smtp-Source: ABdhPJzbNWJXDCv9DlqinGQc2tj9CjBpeFr8VYl8TR+Tc1gqnuRSdYTKhP92CQPSaL9rQuGd52DA4tU6de/eoqE8uAw= X-Received: by 2002:a37:e20d:: with SMTP id g13mr45217219qki.325.1609162203985; Mon, 28 Dec 2020 05:30:03 -0800 (PST) MIME-Version: 1.0 References: <20201218023900.E73B82ACBB2B@ary.qy> <3034face-b6fc-0ce2-fa1b-f59210bd6f5b@tana.it> <46339b38-3b24-bcb7-5e73-8a97038ed69@taugh.com> <3997c81d-3b30-0823-a752-fb1d60a44593@tana.it> <74a5c37-19a6-6f6f-a51d-6e5cca5b29e8@taugh.com> <01RTICXKLL3E0085YQ@mauve.mrochek.com> <8813331f-f5e4-faa5-c6d-11212fc25797@taugh.com> In-Reply-To: <8813331f-f5e4-faa5-c6d-11212fc25797@taugh.com> From: Todd Herr Date: Mon, 28 Dec 2020 08:29:48 -0500 Message-ID: To: IETF DMARC WG Content-Type: multipart/alternative; boundary="0000000000008e0c0305b7864503" Archived-At: Subject: Re: [dmarc-ietf] Ticket #55 - Clarify legal and privacy implications of failure reports X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Dec 2020 13:30:07 -0000 --0000000000008e0c0305b7864503 Content-Type: text/plain; charset="UTF-8" On Thu, Dec 24, 2020 at 1:55 PM John R Levine wrote: > > Security considerations > > Failure reports provide detailed information about the failure of a > single message or a group of similar messages failing for the same > reason. They are meant to aid domain owners to detect why failures > reported in aggregate form occured. It is important to note these > reports can contain either the header or the entire content of a > failed message, which in turn may contain personally identifiable > information, which should be considered when deciding whether to > generate such reports. > > Sorry; late to the party due to the holiday... Is it not also important to note that the recipient of the failure report (the domain owner) may not be the originator of the failed message, and that fact should also weigh into the consideration of deciding whether to generate such reports? If A publishes a DMARC policy record, and a bad actor sends intentionally fraudulent mail using A's domain as the RFC5322.From to addresses that are not among A's current customer base, and therefore unknown to A, sending failure reports to A that don't redact these email addresses reveals PII to A that A has no business receiving. -- *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. --0000000000008e0c0305b7864503 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Dec 24, 2020 at 1:55 PM John R Le= vine <johnl@taugh.com> wrote:<= /div>

Security considerations

Failure reports provide detailed information about the failure of a
single message or a group of similar messages failing for the same
reason. They are meant to aid domain owners to detect why failures
reported in aggregate form occured. It is important to note these
reports can contain either the header or the entire content of a
failed message, which in turn may contain personally identifiable
information, which should be considered when deciding whether to
generate such reports.


Sorry; late to the party due to the ho= liday...

Is it not also important to note that the= recipient of the failure report (the domain owner) may not be the originat= or of the failed message, and that fact should also weigh into the consider= ation of deciding whether to generate such reports?

If A publishes a DMARC policy record, and a bad actor sends intentionally= fraudulent mail using A's domain as the RFC5322.From to addresses that= are not among A's current customer base, and therefore unknown to A, s= ending failure reports to A that don't redact these email addresses rev= eals PII to A that A has no business receiving.

--

Todd Herr | Sr. Technical Program Manager
<= div style=3D"text-align:left">e:= todd.herr@valimail.com
p: 703.220.4153 <= /span>


This email and all data transmitted with it contains confidenti= al and/or proprietary information intended solely for the use of individual= (s) authorized to receive it. If you are not an intended and authorized rec= ipient you are hereby notified of any use, disclosure, copying or distribut= ion 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.

--0000000000008e0c0305b7864503-- From nobody Mon Dec 28 06:12: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 4E3A23A0B6B for ; Mon, 28 Dec 2020 06:12:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dab7_sCuJ058 for ; Mon, 28 Dec 2020 06:12:41 -0800 (PST) Received: from mail-qv1-xf2f.google.com (mail-qv1-xf2f.google.com [IPv6:2607:f8b0:4864:20::f2f]) (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 57BD03A0B68 for ; Mon, 28 Dec 2020 06:12:41 -0800 (PST) Received: by mail-qv1-xf2f.google.com with SMTP id et9so4957847qvb.10 for ; Mon, 28 Dec 2020 06:12:41 -0800 (PST) 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=+6V9vaxrxdupNZVcfOOycJP6vwuBt0spBLKjeQnrI3A=; b=oJBrjSpK7BqnBQDFebHtyZSSh5yOvxZ5oEH21NTc/gboL8yOuKj5tO+3+L5k9K7p0z qfTI0fHYh9HrT6hKG7T+o3pnd7Q6WgQB3xO2y5QP0n3jluKvlz1Wasg884BnrpwJ9GIP cC4BGSlHPuInLTS65+i7hXIIYW+rC2xR/ml8+xP8lD2Pk6aix13mtS3IsxhBI3KxNGWy 4cSi+WuOB84X80uUXB+qMHxD4JjQjWyfkVWjNp5nQyS1XqfKQan1f6hc5yGbywFH90O3 Am/LlkkFB5awHDb6L8gyQoe420vwUJpQHSJwUbKX8f6Q3bQ8E33bfOo9Ktjt8h1vv6vg +d4g== 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=+6V9vaxrxdupNZVcfOOycJP6vwuBt0spBLKjeQnrI3A=; b=j+wahKZk6vP0CIAst/Dh7RMJjJAPPUp/Ovk/bfFfrBL/wiy6tb24HQIvkz/UQnUeZc yetjnpmsZYkC+AwGdEq1nnoeJHSYtLgNoIdcJP+/IYZEx54QKxXQ5C9bySVbZ9E1PQvV BZLMzl76Q9c2Yv16X0/uPNyCgWNbXqDgTsVI1DTED2Gb+6MmZTzjqDaN2gP9hQGbEHxO FFTQRNirbNteORFNcvxIEUX5hwCsQ1eHAAlVe+/zniX0Oebnv+RE2p/BrHww6CG8AWsR Qg4ikqxY7x4cUUKTJYSbSstFbBocus7XiTsdTGJhfYgJDWB3YmWkEq0Zy7d7048qATqR 5tRA== X-Gm-Message-State: AOAM533jAqhiCyUbijB2GWkhuptPojaKYfdamjlokgL0yo2Y+vk4jGDt y1U458HofAsxCTQRGx3tVnpYTi75Pxy7OxK9SJqQ/V7i X-Google-Smtp-Source: ABdhPJyyMMcC4ga+33zhgtWq+JXvxdzW0PD8Uax5r+VS1YdcKXfPSL1PaYzQYU3RvaDymEK1ooaEiFjMqdI2S4Bp+wc= X-Received: by 2002:a0c:dc13:: with SMTP id s19mr47568109qvk.26.1609164760456; Mon, 28 Dec 2020 06:12:40 -0800 (PST) MIME-Version: 1.0 References: <20201218023900.E73B82ACBB2B@ary.qy> <3034face-b6fc-0ce2-fa1b-f59210bd6f5b@tana.it> <46339b38-3b24-bcb7-5e73-8a97038ed69@taugh.com> <3997c81d-3b30-0823-a752-fb1d60a44593@tana.it> <74a5c37-19a6-6f6f-a51d-6e5cca5b29e8@taugh.com> <01RTICXKLL3E0085YQ@mauve.mrochek.com> <8813331f-f5e4-faa5-c6d-11212fc25797@taugh.com> In-Reply-To: From: Dotzero Date: Mon, 28 Dec 2020 09:12:28 -0500 Message-ID: To: Todd Herr Cc: IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000eea30805b786dd1f" Archived-At: Subject: Re: [dmarc-ietf] Ticket #55 - Clarify legal and privacy implications of failure reports X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Dec 2020 14:12:43 -0000 --000000000000eea30805b786dd1f Content-Type: text/plain; charset="UTF-8" On Mon, Dec 28, 2020 at 8:30 AM Todd Herr wrote: > On Thu, Dec 24, 2020 at 1:55 PM John R Levine wrote: > >> >> Security considerations >> >> Failure reports provide detailed information about the failure of a >> single message or a group of similar messages failing for the same >> reason. They are meant to aid domain owners to detect why failures >> reported in aggregate form occured. It is important to note these >> reports can contain either the header or the entire content of a >> failed message, which in turn may contain personally identifiable >> information, which should be considered when deciding whether to >> generate such reports. >> >> > Sorry; late to the party due to the holiday... > > Is it not also important to note that the recipient of the failure report > (the domain owner) may not be the originator of the failed message, and > that fact should also weigh into the consideration of deciding whether to > generate such reports? > > If A publishes a DMARC policy record, and a bad actor sends intentionally > fraudulent mail using A's domain as the RFC5322.From to addresses that are > not among A's current customer base, and therefore unknown to A, sending > failure reports to A that don't redact these email addresses reveals PII to > A that A has no business receiving. > > -- > > *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. > Todd, Would this be akin to the proprietary and confidential information, as indicated in the footer of your email message, which you sent to a publicly accessible list operating under IETF's "Note Well" policy? Some might argue that receipt of this information in DMARC failure reports is a feature and not a bug. Just as the ability to use WHOIS in fighting abuse has been gutted as a result of GDPR, do we really want to go down a path of warning people of "dangers" in such an un-nuanced manner? I agree with John and others that a generic warning regarding security and privacy issues is the more useful approach given that this is a technical standard and vague hand waving is not particularly useful as an implementation guide. For bad guys using/abusing real email addresses as destinations, the privacy ship has sailed as someone somewhere got breached or the addresses got scraped. The same goes for originating From and Mail >From addresses, except the originating domain is already aware of them. Given the choice between writing a book that few will read and even less will understand, and writing a brief generic warning, I choose short and generic. Michael Hammer --000000000000eea30805b786dd1f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Dec 28, 2020 at 8:30 AM Todd = Herr <todd.herr=3D40val= imail.com@dmarc.ietf.org> wrote:
On Thu, Dec 24, 2= 020 at 1:55 PM John R Levine <johnl@taugh.com> wrote:
=

Security considerations

Failure reports provide detailed information about the failure of a
single message or a group of similar messages failing for the same
reason. They are meant to aid domain owners to detect why failures
reported in aggregate form occured. It is important to note these
reports can contain either the header or the entire content of a
failed message, which in turn may contain personally identifiable
information, which should be considered when deciding whether to
generate such reports.


Sorry; late to the party due to the ho= liday...

Is it not also important to note that the= recipient of the failure report (the domain owner) may not be the originat= or of the failed message, and that fact should also weigh into the consider= ation of deciding whether to generate such reports?

If A publishes a DMARC policy record, and a bad actor sends intentionally= fraudulent mail using A's domain as the RFC5322.From to addresses that= are not among A's current customer base, and therefore unknown to A, s= ending failure reports to A that don't redact these email addresses rev= eals PII to A that A has no business receiving.

--

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


This = email and all data transmitted with it contains confidential and/or proprie= tary information intended solely for the use of individual(s) authorized to= receive it. If you are not an intended and authorized recipient you are he= reby notified of any use, disclosure, copying or distribution of the inform= ation included in this transmission is prohibited and may be unlawful. Plea= se immediately notify the sender by replying to this email and then delete = it from your system.

<= div>
Todd,

Would this be akin to the= proprietary and confidential information, as indicated in the footer of yo= ur email message, which you sent to a publicly accessible list operating un= der IETF's "Note Well" policy?=C2=A0 Some might argue that re= ceipt of this information in DMARC failure reports is a feature and not a b= ug. Just as the ability to use WHOIS in fighting abuse has been gutted as a= result of GDPR, do we really want to go down a path of warning people of &= quot;dangers" in such an un-nuanced manner?

I agree = with John and others that a generic warning regarding security and privacy = issues is the more useful approach given that this is a technical standard = and vague hand waving is not particularly useful as an implementation guide= . For bad guys using/abusing real email addresses as destinations, the priv= acy ship has sailed as someone somewhere got breached or the addresses got = scraped. The same goes for originating From and Mail From addresses, except= the originating domain is already aware of them. Given the choice between = writing a book that few will read and even less will understand, and writin= g a brief generic warning, I choose short and generic.=C2=A0

Michael Hammer
--000000000000eea30805b786dd1f-- From nobody Mon Dec 28 07:23: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 575F03A0C23 for ; Mon, 28 Dec 2020 07:23:23 -0800 (PST) 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 ItAt0QSyAyDn for ; Mon, 28 Dec 2020 07:23:22 -0800 (PST) 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 EFD213A0C22 for ; Mon, 28 Dec 2020 07:23:21 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01RTP8ICCY8000DL1N@mauve.mrochek.com> for dmarc@ietf.org; Mon, 28 Dec 2020 07:18:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mrochek.com; s=201712; t=1609168695; bh=FbHvFrfAFv5yLjPxC7hAVdlaGAVR3hCrAP8qDKMutDI=; h=From:Cc:Date:Subject:In-reply-to:References:To:From; b=BLyV6INSsqnJ9XKAGZjo+EmfkzEkUsK+j9EEtzkPHpjtQqVjOnE5HLduCClmyx2re w+lJ49wSFuZXJ8GR9nq4k7bbEqjOgUdkMOggspIr0yNZ38Hn7MUVSvv1XSBrg+rwV7 WrmPwSCho6uTzfNgZuPBgxrm/zYRPW35KS74NSEY= 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 <01RTJOWYX49S004QVR@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for dmarc@ietf.org; Mon, 28 Dec 2020 07:18:08 -0800 (PST) From: ned+dmarc@mrochek.com Cc: John R Levine , Tim Wicinski , IETF DMARC WG Message-id: <01RTP8I70EYI004QVR@mauve.mrochek.com> Date: Mon, 28 Dec 2020 06:54:24 -0800 (PST) In-reply-to: "Your message dated Sat, 26 Dec 2020 11:47:26 +0100" <5d150251-427c-5c44-a0c3-ad2e7f24b692@tana.it> References: <20201218023900.E73B82ACBB2B@ary.qy> <3034face-b6fc-0ce2-fa1b-f59210bd6f5b@tana.it> <46339b38-3b24-bcb7-5e73-8a97038ed69@taugh.com> <3997c81d-3b30-0823-a752-fb1d60a44593@tana.it> <74a5c37-19a6-6f6f-a51d-6e5cca5b29e8@taugh.com> <01RTICXKLL3E0085YQ@mauve.mrochek.com> <8813331f-f5e4-faa5-c6d-11212fc25797@taugh.com> <5d150251-427c-5c44-a0c3-ad2e7f24b692@tana.it> To: Alessandro Vesely Archived-At: Subject: Re: [dmarc-ietf] Ticket #55 - Clarify legal and privacy implications of failure reports X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Dec 2020 15:23:23 -0000 > On Thu 24/Dec/2020 19:55:07 +0100 John R Levine wrote: > >> On Thu 24/Dec/2020 03:39:03 +0100 Tim Wicinski wrote: > >>> I Believe I agree with the current version, but can someone post what we > >>> think is the final text? > > > > See below, with the two changes mentioned before and Mr Copy Edit's minor > > tightening up which I hope are not controversial. > > > > Ale said: > >> I posted it here: > >> https://github.com/ietf-wg-dmarc/draft-ietf-dmarc-failure-reporting > > > > Hold it. I don't recall that we agreed to break failure reports into a separate > > document. > The fact that draft-ietf-dmarc-failure-reporting-00 exists on IETF datatracker > seems to confirm WG consensus. I'm not ethusiastic about the split, but if that's what people want then so be it. I will say that my experience has been that doing so is usually more work and provides less benefit than you'd expect. That said, the adoption of something as a WG document, especially one with an intended status of and in the absence of a corresponding charter update, doesn't really mean much. I also don't see where the discusssion leading to the WG consensus on the split occurred on the mailing list. Perhaps you could point me at it? > But see also: > https://mailarchive.ietf.org/arch/msg/dmarc/2DsSazvE9QxFjVSeg_mdNlRMETM > > It makes more work and I see no agreement to change anything beyond the > > security paragraph. In particular, we have nothing to offer on what one > > might or might not redact. > I still think it'd be a good idea to mention RFC 6590... Why? RFC 6589 documents a generic approach to partial information hiding. It does not specify how to apply this technique to DMARC failure reports, and doing so effectively requires a careful assessment of what needs to be hidden and what does not, and that in turn drags in all of the specifics we need to avoid in a base document of this sort. Indeed, as things stand, since the intent of RFC 6589 is to preserve some information, we can't even say it solves any particular problem with DMARC failure reports. Ned P.S. I hadn't looked at RFC 6589 before, and I have to say I find its standards-track status to be nothing short of astonishing. How on earth do you assess interoperability? From nobody Mon Dec 28 07:48: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 937853A0C16 for ; Mon, 28 Dec 2020 07:48:29 -0800 (PST) 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 NbZNlv_2qvVC for ; Mon, 28 Dec 2020 07:48:27 -0800 (PST) Received: from mail-qt1-x836.google.com (mail-qt1-x836.google.com [IPv6:2607:f8b0:4864:20::836]) (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 333823A03EE for ; Mon, 28 Dec 2020 07:48:27 -0800 (PST) Received: by mail-qt1-x836.google.com with SMTP id b9so7144263qtr.2 for ; Mon, 28 Dec 2020 07:48:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=hMSyDxeWX//91JD+g4WowFBC2xXx1heZZxwCzXKvOt0=; b=UBdBt8BOBLU5VXSGqX7t3wx5hqTzvkMIRSnaluN61oUaSi0oCo8GIS8dJJuhF+2z1e Ru80quTU8uJHEc7buweEcpoBD4adHmolpOFUXcvHFwFwV99h28+JjOClsmDZg0n1ubYn vbXlK/7A97FCFnUGI7axPgz6KebXsuJ68i+FpQkUyPYAsD5NnqSuXBqDo0uRpX/BTGQ3 5opEe1g1fo/lqNxFeV+hnNzNMrhifRdJ3DkB96zLCuxAL38KO1Vb1d/OMQ0Dwv53DwyY HV4jiK22FnS6S83g4YhUzBP6SO8M541MZScywsOqjqtAx3Pj/Gbu6S2kLLUkwDhaA7JM vfcg== 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=hMSyDxeWX//91JD+g4WowFBC2xXx1heZZxwCzXKvOt0=; b=pQDTvDYsLKvKS7HskwZfei6E6FttBv9Zcyz2L1uuI1NwRP2vMWeA0dbGRnwQ1Ey/D/ cIvcSM7/zjxjxTJoQQ/b/zfOdxeRf0kSXYSgmuysxlXXS+PgDILG/FcT3EDgJvNJZVNc tdiXGeFLKKlm+TfI83kTgdtFK/yXZod/wGnxvfL7BfCcfmLkoqGpSsxdd7+68gDS2VAh c7ce4BLDFNbxQ6EUBP0hG5sM4YxZ4Nfun2zqMmc0js+5aDxRtPT4bCaj1ymNRN/P83G5 V+sQciURQFSrbloiUd+dSdWMUx8wZVG+6pIENRzOPeh/0QVBynYpZVxQpBiBwvMNPZvk IRTA== X-Gm-Message-State: AOAM532JvDa01mVFYNBsD+3OPphpJVimurT0PWm7jIgvMDnJTYdxKi9M i/rFf7BaO2DgLsWLlTPlqcv1Wi2fkEpF6Q/RIYworOhit0KVbw== X-Google-Smtp-Source: ABdhPJySVE5DhajMx6oIbDzCp64yjgYTP3KOLY8k8js/l2AJEH+9sv1RrIerhaPqMTDKWN0Vw5G46vb92aQBj4G1mD4= X-Received: by 2002:ac8:5808:: with SMTP id g8mr44432928qtg.208.1609170505831; Mon, 28 Dec 2020 07:48:25 -0800 (PST) MIME-Version: 1.0 References: <20201218023900.E73B82ACBB2B@ary.qy> <3034face-b6fc-0ce2-fa1b-f59210bd6f5b@tana.it> <46339b38-3b24-bcb7-5e73-8a97038ed69@taugh.com> <3997c81d-3b30-0823-a752-fb1d60a44593@tana.it> <74a5c37-19a6-6f6f-a51d-6e5cca5b29e8@taugh.com> <01RTICXKLL3E0085YQ@mauve.mrochek.com> <8813331f-f5e4-faa5-c6d-11212fc25797@taugh.com> In-Reply-To: From: Todd Herr Date: Mon, 28 Dec 2020 10:48:10 -0500 Message-ID: To: IETF DMARC WG Content-Type: multipart/alternative; boundary="00000000000062299605b7883412" Archived-At: Subject: Re: [dmarc-ietf] Ticket #55 - Clarify legal and privacy implications of failure reports X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Dec 2020 15:48:30 -0000 --00000000000062299605b7883412 Content-Type: text/plain; charset="UTF-8" On Mon, Dec 28, 2020 at 9:12 AM Dotzero wrote: > > > On Mon, Dec 28, 2020 at 8:30 AM Todd Herr 40valimail.com@dmarc.ietf.org> wrote: > >> On Thu, Dec 24, 2020 at 1:55 PM John R Levine wrote: >> >>> >>> Security considerations >>> >>> Failure reports provide detailed information about the failure of a >>> single message or a group of similar messages failing for the same >>> reason. They are meant to aid domain owners to detect why failures >>> reported in aggregate form occured. It is important to note these >>> reports can contain either the header or the entire content of a >>> failed message, which in turn may contain personally identifiable >>> information, which should be considered when deciding whether to >>> generate such reports. >>> >>> >> Sorry; late to the party due to the holiday... >> >> Is it not also important to note that the recipient of the failure report >> (the domain owner) may not be the originator of the failed message, and >> that fact should also weigh into the consideration of deciding whether to >> generate such reports? >> >> If A publishes a DMARC policy record, and a bad actor sends intentionally >> fraudulent mail using A's domain as the RFC5322.From to addresses that are >> not among A's current customer base, and therefore unknown to A, sending >> failure reports to A that don't redact these email addresses reveals PII to >> A that A has no business receiving. >> >> > Todd, > > Would this be akin to the proprietary and confidential information, as > indicated in the footer of your email message, which you sent to a publicly > accessible list operating under IETF's "Note Well" policy? Some might > argue that receipt of this information in DMARC failure reports is a > feature and not a bug. Just as the ability to use WHOIS in fighting abuse > has been gutted as a result of GDPR, do we really want to go down a path of > warning people of "dangers" in such an un-nuanced manner? > > I agree with John and others that a generic warning regarding security and > privacy issues is the more useful approach given that this is a technical > standard and vague hand waving is not particularly useful as an > implementation guide. For bad guys using/abusing real email addresses as > destinations, the privacy ship has sailed as someone somewhere got breached > or the addresses got scraped. The same goes for originating From and Mail > From addresses, except the originating domain is already aware of them. > Given the choice between writing a book that few will read and even less > will understand, and writing a brief generic warning, I choose short and > generic. > > Michael Hammer > Michael, I am not opposed to the generic warning, but the following sentence in the proposed warning gives me pause: "They are meant to aid domain owners to detect why failures reported in aggregate form occured." The implication, to me, in that sentence is that the failure report will be sent to the party that originated the message, and that's not always going to be true. All failure reports will be sent to the domain owner, but the domain owner will not always be the originating party for the message in the failure report. I'm not a lawyer, but providing A with some information about a message that A sent to X seems different, from a privacy perspective, than providing A with some information about a message impersonating A that B sent to X, and I thought perhaps the generic warning might mention this distinction, if possible. Something like: Security considerations Failure reports provide detailed information about the failure of a single message or a group of similar messages failing for the same reason. They are meant to aid domain owners to detect why failures reported in aggregate form occured. It is important to note these reports can contain either the header or the entire content of a failed message, AND THAT THE DOMAIN OWNER RECEIVING THE REPORTS MAY NOT BE THE ORIGINATING PARTY FOR THE MESSAGE(S) REFERENCED IN THE FAILURE REPORTS. IN ANY CASE, THEY may contain personally identifiable information, which should be considered when deciding whether to generate such reports. -- *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. --00000000000062299605b7883412 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Dec 28, 2020 at 9:12 AM Dotze= ro <dotzero@gmail.com> wrote= :


On Mon, Dec 28, 2020 at 8:30 AM Todd Herr <todd.= herr=3D4= 0valimail.com@dmarc.ietf.org> wrote:
On Thu, Dec 2= 4, 2020 at 1:55 PM John R Levine <johnl@taugh.com> wrote:

Security considerations

Failure reports provide detailed information about the failure of a
single message or a group of similar messages failing for the same
reason. They are meant to aid domain owners to detect why failures
reported in aggregate form occured. It is important to note these
reports can contain either the header or the entire content of a
failed message, which in turn may contain personally identifiable
information, which should be considered when deciding whether to
generate such reports.


Sorry; late to the party due to the ho= liday...

Is it not also important to note that the= recipient of the failure report (the domain owner) may not be the originat= or of the failed message, and that fact should also weigh into the consider= ation of deciding whether to generate such reports?

If A publishes a DMARC policy record, and a bad actor sends intentionally= fraudulent mail using A's domain as the RFC5322.From to addresses that= are not among A's current customer base, and therefore unknown to A, s= ending failure reports to A that don't redact these email addresses rev= eals PII to A that A has no business receiving.


Todd,

Wo= uld this be akin to the proprietary and confidential information, as indica= ted in the footer of your email message, which you sent to a publicly acces= sible list operating under IETF's "Note Well" policy?=C2=A0 S= ome might argue that receipt of this information in DMARC failure reports i= s a feature and not a bug. Just as the ability to use WHOIS in fighting abu= se has been gutted as a result of GDPR, do we really want to go down a path= of warning people of "dangers" in such an un-nuanced manner?
=
I agree with John and others that a generic warning regardin= g security and privacy issues is the more useful approach given that this i= s a technical standard and vague hand waving is not particularly useful as = an implementation guide. For bad guys using/abusing real email addresses as= destinations, the privacy ship has sailed as someone somewhere got breache= d or the addresses got scraped. The same goes for originating From and Mail= From addresses, except the originating domain is already aware of them. Gi= ven the choice between writing a book that few will read and even less will= understand, and writing a brief generic warning, I choose short and generi= c.=C2=A0

Michael Hammer

Michael,

I am not oppo= sed to the generic warning, but the following sentence in the proposed warn= ing gives me pause:

"= They are meant to aid domain owners to detect why failures=C2=A0reported in aggregate form occured."=C2= =A0

The implication, to m= e, in that sentence is that the failure report will be sent to the party th= at originated the message, and that's not always going to be true. All = failure reports will be sent to the domain owner, but the domain owner will= not always be the originating party for the message in the failure report.=

I'm not a lawyer, but providing A with some i= nformation about a message that A sent to X seems different, from a privacy= perspective, than providing A with some information about a message impers= onating A that B sent to X, and I thought perhaps the generic warning might= mention this distinction, if possible. Something like:

Security considerations

Failure reports provide detailed information about the failure of a
single message or a group of similar messages failing for the same
reason. They are meant to aid domain owners to detect why failures
reported in aggregate form occured. It is important to note these
reports can contain either the header or the entire content of a
failed message, AND THAT THE DOMAIN OWNER RECEIVING THE
REPORTS MAY NOT BE THE ORIGINATING PARTY FOR THE MESSAGE(S)
REFERENCED IN THE FAILURE REPORTS. IN ANY CASE, THEY may contain=C2= =A0
personally identifiable information, which should = be considered when deciding=C2=A0
whether to generate = such reports.

--

Todd Herr | Sr. Tec= hnical Program Manager
= p: 703.220.4153
=


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

--00000000000062299605b7883412-- From nobody Mon Dec 28 07:57: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 B23613A0C45 for ; Mon, 28 Dec 2020 07:57:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.748 X-Spam-Level: X-Spam-Status: No, score=-1.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mtcc.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 wuUoa2T0YRSm for ; Mon, 28 Dec 2020 07:57:48 -0800 (PST) Received: from mail-pg1-x52f.google.com (mail-pg1-x52f.google.com [IPv6:2607:f8b0:4864:20::52f]) (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 6307B3A0C43 for ; Mon, 28 Dec 2020 07:57:48 -0800 (PST) Received: by mail-pg1-x52f.google.com with SMTP id e2so7546292pgi.5 for ; Mon, 28 Dec 2020 07:57:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mtcc.com; s=fluffulence; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=Gs+JksViCPvHwe5GGDEvZeC53Gqq8pQF9ahpx+hoNhk=; b=V925eeGHkP6fHic645ldHR6t1pu0JJ/VpTuGCFN8WvqhOipp018ytyTQwkIqAN1W13 6L2CTZOz+8N0NfZ8jMS1Q6wBBEcssxtvMZLpQFE0/tZdw0ErNjKdzAj7LOBBUCa9kwfh Uaar9L3ZDzbS7+vicVJnfif77enkvn6BwnLhD0BahpIAGy1gwfQ4z105pDlGpnWgtRNr NyFBfgYTBA3coQs03bLOGny2o2SZUvEEBQMXIUjmngCA8tkx2RkZmkfLQMkMv1EsrV31 t1MpgbQ6bGHiL1/k/8qoC6o0NzsZW2YEOf1B/xEB9zLJ5s1Vh6xvqRULASaDvH8GN2CM Ez6w== 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=Gs+JksViCPvHwe5GGDEvZeC53Gqq8pQF9ahpx+hoNhk=; b=eEMLzRdRumz/Y5NH4wMjL15Vcm0P2RsblcdINLjQ/1FhJ1FyraSeBoATEBNc+74AIo AH7J85CBVmqxzcqrVNwUQKWCw2k4Ipx5Sih8G39/0rVbSAYuuT5vQQa3Up7gr1xaaNri SDoNFwFAd3iWjYbVPD8dQfsTRsw9+fxBuyRWdS2ImSPE2SW79wo0L3LY5lCKf+hEOqCb ltbWH5WBcDP5C2D2frhxS7pyRfNJG6Gx+ysoxpK9qtAIUMSS8szq6YIWUTXhOTis4Y1s f5U4+DX6Vz+wfST+xhnPstePUSuAOH9ZiqcxPTGWYsFHU2Tef9iByaTJxiuPdbfZ74bs XPow== X-Gm-Message-State: AOAM531CZjIsgOHzpWvq8WgjgWEYUhxZLKYjNFsChvR4NVD0sNiJy2mu e/mVvOxLRcoUsTAN27gPPFNX6OnBZyLlqA== X-Google-Smtp-Source: ABdhPJzWO85JiKaLsgD73JkU6HQhGGIC1R7A7YlRSdPN1kaIyMr3JstJ6qjax8p43JRT2cdeCQKwcA== X-Received: by 2002:a63:d814:: with SMTP id b20mr9013556pgh.202.1609171067407; Mon, 28 Dec 2020 07:57:47 -0800 (PST) Received: from mike-mac.lan ([107.182.37.0]) by smtp.gmail.com with ESMTPSA id t36sm34155342pfg.55.2020.12.28.07.57.46 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 28 Dec 2020 07:57:46 -0800 (PST) To: dmarc@ietf.org References: <20201218023900.E73B82ACBB2B@ary.qy> <3997c81d-3b30-0823-a752-fb1d60a44593@tana.it> <74a5c37-19a6-6f6f-a51d-6e5cca5b29e8@taugh.com> <01RTICXKLL3E0085YQ@mauve.mrochek.com> <8813331f-f5e4-faa5-c6d-11212fc25797@taugh.com> From: Michael Thomas Message-ID: <3cd0c105-4864-2cbc-7d4c-3a27ccb2dce4@mtcc.com> Date: Mon, 28 Dec 2020 07:57:45 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------134BB9B2743E67C47E787049" Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] Ticket #55 - Clarify legal and privacy implications of failure reports X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Dec 2020 15:57:50 -0000 This is a multi-part message in MIME format. --------------134BB9B2743E67C47E787049 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 12/28/20 7:48 AM, Todd Herr wrote: >  not a lawyer, but providing A with some information about a message > that A sent to X seems different, from a privacy perspective, than > providing A with some information about a message impersonating A that > B sent to X, and I thought perhaps the generic warning might mention > this distinction, if possible. Something like: > > Security considerations > > Failure reports provide detailed information about the failure of a > single message or a group of similar messages failing for the same > reason. They are meant to aid domain owners to detect why failures > reported in aggregate form occured. It is important to note these > reports can contain either the header or the entire content of a > failed message, AND THAT THE DOMAIN OWNER RECEIVING THE > REPORTS MAY NOT BE THE ORIGINATING PARTY FOR THE MESSAGE(S) > REFERENCED IN THE FAILURE REPORTS. IN ANY CASE, THEY may contain > personally identifiable information, which should be considered > when deciding > whether to generate such reports. > > This is a tempest in a tea pot. This is an issue with the originating domain and nobody else. They can send it to a third party even if the url lists them to receive the report first.  The receiving domain can't know what they will do with the report, and the originating domain has already seen the mail in clear text before it was sent. IETF should stay out of the business of being nannies that it has no way to enforce. Mike --------------134BB9B2743E67C47E787049 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit


On 12/28/20 7:48 AM, Todd Herr wrote:
 not a lawyer, but providing A with some information about a message that A sent to X seems different, from a privacy perspective, than providing A with some information about a message impersonating A that B sent to X, and I thought perhaps the generic warning might mention this distinction, if possible. Something like:

Security considerations

Failure reports provide detailed information about the failure of a
single message or a group of similar messages failing for the same
reason. They are meant to aid domain owners to detect why failures
reported in aggregate form occured. It is important to note these
reports can contain either the header or the entire content of a
failed message, AND THAT THE DOMAIN OWNER RECEIVING THE
REPORTS MAY NOT BE THE ORIGINATING PARTY FOR THE MESSAGE(S)
REFERENCED IN THE FAILURE REPORTS. IN ANY CASE, THEY may contain 
personally identifiable information, which should be considered when deciding 
whether to generate such reports.


This is a tempest in a tea pot. This is an issue with the originating domain and nobody else. They can send it to a third party even if the url lists them to receive the report first.  The receiving domain can't know what they will do with the report, and the originating domain has already seen the mail in clear text before it was sent. IETF should stay out of the business of being nannies that it has no way to enforce.

Mike

--------------134BB9B2743E67C47E787049-- From nobody Mon Dec 28 07:58: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 AF7A73A0C46 for ; Mon, 28 Dec 2020 07:58:57 -0800 (PST) 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=ku+Fxjd6; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=owdAJKZf Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tEpSCWbbmd35 for ; Mon, 28 Dec 2020 07:58:55 -0800 (PST) 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 DA7A63A0C45 for ; Mon, 28 Dec 2020 07:58:54 -0800 (PST) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha256; c=simple/relaxed; l=5634; t=1609171128; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=Kv4GS5o1wmuVkQrHVKDbyX6X585E DAPRC7su/pcp4S4=; b=ku+Fxjd6XB+B6Fewc4MZfeTJYolR+ZYMNryfOnKShpFA mw4UTdDmmFMszEmFbY24/yQhl17USWp4uNlWY9rWVnjc7XPGAz1Z6zPdS9EjY2E0 MfNilAzBs4u9GuoPtJ764xH0GM7whrmPxIrM9TWMh9Ic0bjauYMSUJt6euGjWLk= Received: by mail.winserver.com (Wildcat! SMTP Router v8.0.454.10) for dmarc@ietf.org; Mon, 28 Dec 2020 10:58:48 -0500 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 2611193784.16935.652; Mon, 28 Dec 2020 10:58:47 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=5634; t=1609170756; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=Kv4GS5o 1wmuVkQrHVKDbyX6X585EDAPRC7su/pcp4S4=; b=owdAJKZf3BNwwMxYt+Tcg8x aZyKuU0494ICdACzk9Yi1vpxctwlREVCTJbjFwldm2pCKIyNp6/xG4xGTV1Q/Y4p 9hyss2Y1yJbYZj2pBiAoiZigHLSiKkkcwzLSNn7cUVaYN26Nh+G9maj/FAFZYB9j MfLjwvMaQn858LxUAwMo= Received: by beta.winserver.com (Wildcat! SMTP Router v8.0.454.10) for dmarc@ietf.org; Mon, 28 Dec 2020 10:52:36 -0500 Received: from [192.168.1.68] ([75.26.216.248]) by beta.winserver.com (Wildcat! SMTP v8.0.454.10) with ESMTP id 2478060720.1.6928; Mon, 28 Dec 2020 10:52:35 -0500 Message-ID: <5FEA00B3.7050902@isdg.net> Date: Mon, 28 Dec 2020 10:58:43 -0500 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: Todd Herr , Michael Thomas CC: "dmarc@ietf.org" References: <9f6782b1-e85b-1a9c-9151-98feff7e18ea@mtcc.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] auth-res vs. dmarc X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Dec 2020 15:58:58 -0000 On 12/28/2020 8:17 AM, Todd Herr wrote: > On Sat, Dec 26, 2020 at 6:48 PM Michael Thomas > wrote: > > > I installed this handy dandy t-bird dkim verifier extension which > also > allows you to just use the upstream auth-res. After fixing a bug > in it, > I could see that it lists DMARC as a fail when DKIM failed, but SPF > passed. The _dmarc record has p=none, so it seems really odd to call > that a DMARC failure. Shouldn't it just be using the appropriate > p= tag > instead of "fail"? Is this left over from when Auth-res was mainly > for dkim? > > > A DMARC pass verdict requires not only that SPF or DKIM pass, but also > that the SPF or DKIM domain in question align with the DMARC > (RFC5322.From) domain. A message such as the following: > > * Return-Path: > > * DKIM domain: b.org > * From: bar@c.com > > Can get an SPF pass for a.net and have its DKIM > signature validate, but still fail DMARC for c.com > because neither a.net nor b.org align > with c.com . > > Can you share the example auth-res header(s) in question along with > the DMARC policy record(s) for the message(s)? > -- FWIW.... For your message, the wcSMTP MDA verified and produced the follow AR for you: Authentication-Results: dkim.winserver.com; dkim=pass header.d=ietf.org header.s=ietf1 header.i=ietf.org; dmarc=fail policy=none author.d=dmarc.ietf.org signer.d=ietf.org (unauthorized signer); dkim=fail (DKIM_SIGNATURE_BAD) header.d=ietf.org header.s=ietf1 header.i=ietf.org; dmarc=dkim-fail policy=none author.d=dmarc.ietf.org signer.d=ietf.org (unauthorized signer); dkim=fail (DKIM_BODY_HASH_MISMATCH) header.d=valimail.com header.s=google2048 header.i=valimail.com; dmarc=dkim-fail policy=none author.d=dmarc.ietf.org signer.d=valimail.com (unauthorized signer); bottom up read, By the time your message (my list copy) was echoed to me, as expected with the ietf.org MLM, your original body integrity was lost, hence a body-mismatch will be detected with all downlink DKIM verifiers. The original DKIM idea for MLM correction (or middle-ware in general) was to perform a resigning by the MLM as a 3rd party signer. But we never corrected the authorization protocol for the 3rd party signers like is done with SPF allowing for 3rd party mailers to exist within it output mail sender framework. Here is the problem with rewriting which the AR recorded illustrates -- who is the POLICY holder here? You or the IETF (ietf.org or dmarc.ietf.org)? Valmail.com does not have a policy, like ATPS, that will authorized ietf.org or dmarc.ietf.org as a resigner. If you had this zone record: ; ; DMARC/ATPS Zone Records for author-domain: valimail.com ; Generated by wcMakeDMARC v4.00 (c) copyright 2020 Santronics Software, Inc. ; See https://secure.winserver.com/public/wcdmarc ; _dmarc TXT ("v=dmarc1; p=reject; atps=y; asl=ietf.org,dmarc.ietf.org;") pq6xadozsi47rluiq5yohg2hy3mvjyoo._atps TXT ("v=atps01; d=ietf.org;") xxv4fo4ieaguvlupvusha3j2x7ici4za._atps TXT ("v=atps01; d=dmarc.ietf.org;") Then our wcDMARC verifier would validate your message and stamp the AR with an authorized resigner data bit. However, this is true when rewriting is not applied. In practice, we have a "contract" as a list member to accept what the IETF MLM does, to a degree, to receive its output. But I don't expect any original protection to be lost. Valimail.com was protected on input. On output, it was no longer protected once it passes through the IETF MLM. Consider a rewrite is not correct when it used two different domains. My understanding for the intent of this unfortunate introduction into the mail world, the whole point was make it a 1st party signature so that the author and signer identities matched: ADID Author Identity: dmarc.ietf.org SDID Signer Identity: ietf.org <--- SHOULD BE signed by dmarc.ietf.org Even if it was signed by dmarc.ietf.org, its DMARC policy is p=none, so who cares what is done with valimail.com messages? Product engineering common sense is to not destroy the original policy protection Valimail.com had. If the rewrite logic is going to be applied only when an incoming domain has a DMARC p=reject|quarantine policy, then the rewrite MUST have a matching level of protection when it changes the author identity To me, this is the only possible way for a rewrite mlm logic to minimize the damage created by destroying the original intent and protection of a DMARC-based restricted domain. This failure is feeding any anticipated growth for "Deep AI Mail engines" that indicate valimail.com has a significant failure rate, 100% of the time coming out of the IETF. If I was valimail.com, as a product developer, you should support the easy ATPS protocol. Just add the domains you want to authorized as a resigner and hopefully with ATPS endorsement by ValiMail, adding it to your product line will give you and customers protection, immediately, in the eyes of my wcDMARC receivers and verifiers. BTW, these are my authorized 3rd party resigners for my personal sandbox domain: isdg.net kjshf2duqstols65zbhuytbbyr3zdecf._atps TXT ( "v=atps01; d=gmail.com;" ) pq6xadozsi47rluiq5yohg2hy3mvjyoo._atps TXT ( "v=atps01; d=ietf.org;" ) jchjykxmwknbyfge2bg4td6add264olh._atps TXT ( "v=atps01; d=winserver.com;" ) -- Hector Santos, https://secure.santronics.com https://twitter.com/hectorsantos From nobody Mon Dec 28 08:14: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 AC4783A0C57 for ; Mon, 28 Dec 2020 08:14:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WfkygDW8Lqxv for ; Mon, 28 Dec 2020 08:14:54 -0800 (PST) Received: from mail-ot1-x329.google.com (mail-ot1-x329.google.com [IPv6:2607:f8b0:4864:20::329]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E595F3A0C53 for ; Mon, 28 Dec 2020 08:14:53 -0800 (PST) Received: by mail-ot1-x329.google.com with SMTP id o11so9539122ote.4 for ; Mon, 28 Dec 2020 08:14:53 -0800 (PST) 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=pLrsFqdk4O7eCDCCYux2liEC5Mvpq6qf5rxbB1CfTIM=; b=m4kKvVK0DFS6raS8qncufD8V6aBV6f5MieGYpm0326LBLaNBLI4327rZg30myiP04u A0DRjCeAbvfQmeBCTNKG4sZrxReiF6ArkKt9gBys0xKbiQDp3k3ira+xEOCPPhUFwnfN KVYUsvEe4+uKlO/ra8lOm/ULSzfA8Hd99jj2ECwpnL1ghHtm9GCw+RdPsctqhACPdDpp 8bT+SqmQjGJMXtpdx//3WdPXZ872sY3VI4DcPkk5R3mBKD9rx/QKQQMRAt8KIUAoK+gQ 011RLB5am5EH75ja1qIw68MAPUjfGIY7uUEIL387VMnKZNz5oU7bDtQtEyFeZRkQye3c 1GvQ== 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=pLrsFqdk4O7eCDCCYux2liEC5Mvpq6qf5rxbB1CfTIM=; b=aRn3r5q+bxRYj/4juUj37tfPm0ju6iPDmq0qbZw8k1OxUrvJmMfAwyrTj/izHs9dL4 wXlIKVc5akrMfkh4lPvI9FGyMXCBWd4CPjIJncWDzsv4XV0l17DZdI3xXHF9lTamaDwk PvEgZgp3GqKJe7jMego2w0WKGjHMNBW9vdsfaqVM7nVvyNs4wwFyoWEOkwKB2Muq6Qm2 nItep0ObKaI7fk+tapyGZTBcMNHC4LVEhTUHFC7vDIxtxLmyciLwi0oyGjzFyi24B3ZN Lt6DG6MLnRrQ4YvAMChBg5TDPNRzaFFmSdlm3KjtFlxIEB7ykEP9/IOTa2uPAxgat+BD LVqA== X-Gm-Message-State: AOAM532dd9jfDhfESACWLyCj5ZJuWU6+6QH/B+CLRcFeyfUaPRctjJGf oHRBgjoCjj/qjd8ld4NFekh6rdmlD/aRx0TjK9z4oou0 X-Google-Smtp-Source: ABdhPJxLDiYR6mflebkYQcQcSQudnQe3ESqqOIU/dNCXdLig3Dcz9ORWKfRZusNsiWrS56pPg1Mi39cMkfbkYyq/LTo= X-Received: by 2002:a05:6830:104f:: with SMTP id b15mr33929802otp.155.1609172092938; Mon, 28 Dec 2020 08:14:52 -0800 (PST) MIME-Version: 1.0 References: <20201218023900.E73B82ACBB2B@ary.qy> <3997c81d-3b30-0823-a752-fb1d60a44593@tana.it> <74a5c37-19a6-6f6f-a51d-6e5cca5b29e8@taugh.com> <01RTICXKLL3E0085YQ@mauve.mrochek.com> <8813331f-f5e4-faa5-c6d-11212fc25797@taugh.com> <3cd0c105-4864-2cbc-7d4c-3a27ccb2dce4@mtcc.com> In-Reply-To: <3cd0c105-4864-2cbc-7d4c-3a27ccb2dce4@mtcc.com> From: Tim Wicinski Date: Mon, 28 Dec 2020 11:14:41 -0500 Message-ID: To: IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000fb6ae105b7889225" Archived-At: Subject: Re: [dmarc-ietf] Ticket #55 - Clarify legal and privacy implications of failure reports X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Dec 2020 16:14:56 -0000 --000000000000fb6ae105b7889225 Content-Type: text/plain; charset="UTF-8" I would drop that whole third sentence, and mention sending such reports may contain PII. The document can refer the reader to non-IETF documents for information, but in general we do technical standards, and stay away from policy decisions in standards track documents. tim On Mon, Dec 28, 2020 at 10:57 AM Michael Thomas wrote: > > On 12/28/20 7:48 AM, Todd Herr wrote: > > not a lawyer, but providing A with some information about a message that > A sent to X seems different, from a privacy perspective, than providing A > with some information about a message impersonating A that B sent to X, and > I thought perhaps the generic warning might mention this distinction, if > possible. Something like: > > Security considerations > > Failure reports provide detailed information about the failure of a > single message or a group of similar messages failing for the same > reason. They are meant to aid domain owners to detect why failures > reported in aggregate form occured. It is important to note these > reports can contain either the header or the entire content of a > failed message, AND THAT THE DOMAIN OWNER RECEIVING THE > REPORTS MAY NOT BE THE ORIGINATING PARTY FOR THE MESSAGE(S) > REFERENCED IN THE FAILURE REPORTS. IN ANY CASE, THEY may contain > personally identifiable information, which should be considered when > deciding > whether to generate such reports. > > > > This is a tempest in a tea pot. This is an issue with the originating > domain and nobody else. They can send it to a third party even if the url > lists them to receive the report first. The receiving domain can't know > what they will do with the report, and the originating domain has already > seen the mail in clear text before it was sent. IETF should stay out of the > business of being nannies that it has no way to enforce. > > Mike > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > --000000000000fb6ae105b7889225 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

I= would drop that whole third sentence, and mention sending such reports may= contain PII.=C2=A0=C2=A0
The document can refer the reader to non-IETF documents fo= r information, but in general
we do technical standards, and stay away from policy d= ecisions in standards track documents.=C2=A0


tim


On Mon, Dec 28, 2020 at 10:57 AM Michael T= homas <mike@mtcc.com> wrote:
=
=20 =20 =20


On 12/28/20 7:48 AM, Todd Herr wrote:
=20
=C2=A0not a lawyer, but providing A with some information about a message that A sent to X seems different, from a privacy perspective, than providing A with some information about a message impersonating A that B sent to X, and I thought perhaps the generic warning might mention this distinction, if possible. Something like:

Security considerations

Failure reports provide detailed information about the failure of a
single message or a group of similar messages failing for the same
reason. They are meant to aid domain owners to detect why failures
reported in aggregate form occured. It is important to note these
reports can contain either the header or the entire content of a
failed message, AND THAT THE DOMAIN OWNER RECEIVING THE
REPORTS MAY NOT BE THE ORIGINATING PARTY FOR THE MESSAGE(S)
REFERENCED IN THE FAILURE REPORTS. IN ANY CASE, THEY may contain=C2=A0
personally identifiable information, which should be considered when deciding=C2=A0
whether to generate such reports.


This is a tempest in a tea pot. This is an issue with the originating domain and nobody else. They can send it to a third party even if the url lists them to receive the report first.=C2=A0 T= he receiving domain can't know what they will do with the report, an= d the originating domain has already seen the mail in clear text before it was sent. IETF should stay out of the business of being nannies that it has no way to enforce.

Mike

_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
--000000000000fb6ae105b7889225-- From nobody Mon Dec 28 09:06: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 AF9693A0C90 for ; Mon, 28 Dec 2020 09:06:22 -0800 (PST) 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_DNSWL_BLOCKED=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iecc.com header.b=sFQNSYZC; dkim=pass (2048-bit key) header.d=taugh.com header.b=j+tj+W8R Received: 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_CV8-_J4z82 for ; Mon, 28 Dec 2020 09:06:21 -0800 (PST) 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 264533A0C8A for ; Mon, 28 Dec 2020 09:06:20 -0800 (PST) Received: (qmail 73507 invoked from network); 28 Dec 2020 17:06:19 -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=11f1b.5fea108b.k2012; i=johnl-iecc.com@submit.iecc.com; bh=N7PO/vyJtHVbHsO979ZTQZH4agZLYeflKvFpFUp92Iw=; b=sFQNSYZCxrAt3A6oS7Cq2Hmxbr15nzgkUq4WnqMLph3WOw2LvYZbbmXkADYQE8r8qrWW9EZ0IQCpflwanzegoo3lFW9nJ3hkiNorzHG80ifV0j12TvbWsUXGCNEK5m+Yh8M8tj9Eke+GdUVae9n8+qOnb4BfCOwDM63j9ylXZRYzs06kn/ydPD8MPVAGpugotGIzdSV76MlSF8/5DAU976bm/jStfGFezjJOwVFmAxy8mgb1VL4rRcuAZheTNVNWbNPXI2IA8osI1+5FheBv44BGSNtmIVQ5Jp4U1duWnE6UeLWsZ0DmaOmF0FtntYzFWM6nVTIFsVd0F0DN5dcj0A== 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=11f1b.5fea108b.k2012; olt=johnl-iecc.com@submit.iecc.com; bh=N7PO/vyJtHVbHsO979ZTQZH4agZLYeflKvFpFUp92Iw=; b=j+tj+W8R4aR06EqtXITTfWqiwt/kC7sOK9LLylRt47HrzSMtuGeGmVu3kiBjkO/ARULzAzB0uyM418wZqyrBhG6Yp6xGjVrqEzuY2e74G4n5ncOR17/YtTqQWh9vR0EGGuZejKR6J8kn8WQFCGobru8hQwUtouo9iM2/Z64j7QSAGFv726NsqqYEUG7pOSZeiK7TzirJWAUOGHljfBMMR+um9ozR3gFutK+IblXnF1ro6SFZbIdOQH1hgMiSBYdE3ca3hAUYWGitJkcaYXbPgfGYmQNKENr2VkVjvUl+HHrPzhjjIFdIQ5lcrpS1iCizlTr8t/davnOpklbpW1vEOg== 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 Dec 2020 17:06:19 -0000 Date: 28 Dec 2020 12:06:18 -0500 Message-ID: <6a4a11ea-fae2-81f5-ce5f-fbd4bc1d41e2@taugh.com> From: "John R Levine" To: "Ned Freed" Cc: "IETF DMARC WG" In-Reply-To: <01RTP8I70EYI004QVR@mauve.mrochek.com> References: <20201218023900.E73B82ACBB2B@ary.qy> <3034face-b6fc-0ce2-fa1b-f59210bd6f5b@tana.it> <46339b38-3b24-bcb7-5e73-8a97038ed69@taugh.com> <3997c81d-3b30-0823-a752-fb1d60a44593@tana.it> <74a5c37-19a6-6f6f-a51d-6e5cca5b29e8@taugh.com> <01RTICXKLL3E0085YQ@mauve.mrochek.com> <8813331f-f5e4-faa5-c6d-11212fc25797@taugh.com> <5d150251-427c-5c44-a0c3-ad2e7f24b692@tana.it> <01RTP8I70EYI004QVR@mauve.mrochek.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [dmarc-ietf] reporting documents, Ticket #55 - Clarify legal and privacy implications of failure reports X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Dec 2020 17:06:23 -0000 On Mon, 28 Dec 2020, Ned Freed wrote: > I'm not ethusiastic about the split, but if that's what people want then so be > it. I will say that my experience has been that doing so is usually more work > and provides less benefit than you'd expect. I recall agreeing to split out all of the reporting into a separate draft, which makes some sense so the two parts can proceed separately, but not further splitting aggregate and failure reports. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From nobody Mon Dec 28 10:00: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 23BAF3A0CCE for ; Mon, 28 Dec 2020 10:00:26 -0800 (PST) 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 LZgI2SvoIzhF for ; Mon, 28 Dec 2020 10:00:24 -0800 (PST) Received: from mail-oi1-x230.google.com (mail-oi1-x230.google.com [IPv6:2607:f8b0:4864:20::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B2F93A0CCD for ; Mon, 28 Dec 2020 10:00:24 -0800 (PST) Received: by mail-oi1-x230.google.com with SMTP id q25so12187105oij.10 for ; Mon, 28 Dec 2020 10:00:24 -0800 (PST) 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=30KRFiERt4rA28AMkuJN7wLUWlIlplKV5rjHoRCz0oE=; b=Gv/Yrd1tDMwrpFblCE00MgUMjxypUt6Zjw8iJClV7lqxSbt1DiNXqjOwW9FOnxlo0I 2D/UUBIbn6O9RiEWud2NhLtN2bPS4MIAtCsY0GhHZK3B6wzIsu9y5vKcOGJGO/plRdgO XYy6K634RHeiWlDJkZxr1vJL2w+wETmPFGarODVygvIub6VGBJ07EIplt1foSWd62tK1 d/txkl5idgkv9Bvprse1Dc2WeuSkvNbCrsFfGD1kdQjrYPX3YqQwvurom1oo67VyZmhh bFd5rLRqBCAVPL42NbQHdYJ7VZ542szS88xzzaYJw/VDk8p992DmGnI+KskoluRlk+PJ VB5w== 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=30KRFiERt4rA28AMkuJN7wLUWlIlplKV5rjHoRCz0oE=; b=sB0YRXc8OfHXU9L7edScg3DVu0nuJljfhl9rzXlbQq97vUgoHWBwV6Q9SRppHGZlun o4WMYVDAeduFcTT78vyyG7T1gFMtMde/5RYP9SuN9iKWtXjmcbMEMVhLXTt/8q6cqJB8 4frNN296jHdOtvF+a5uYiIVZl+8xCvxD2xolhpptAUEP6VInGSEAyvqHJHDgbkIkKF/L Ers/bRFS1icLrw9M0FBc0+p6Z3XB6IGTGhnE7bxebVrGly+aCNOcFEeMip1n8yV7HHfh x9e16iJ8PB41lEObNoeB3/f2wpor7JScJaDsh6PdW0EFNl1xT25is2MR1wq6IuLV6mug 3B3w== X-Gm-Message-State: AOAM530bBWDpNtvSBrGe6cFJSCLt7kDz2ZisSmPfmbgUhequnn5t6njF wegyuR4JcnthTQ8tYtdZB6R3Bol1tRSQ/kQOf/o= X-Google-Smtp-Source: ABdhPJx9YOm/Y0RrPTdK04uC58o4AI+INUJgoZeMElokcuYy/c7OBL/44YTgbpoFssIMC4oIAhjWRXh0bwCbQJ8tlsQ= X-Received: by 2002:aca:c3c6:: with SMTP id t189mr47527oif.21.1609178423682; Mon, 28 Dec 2020 10:00:23 -0800 (PST) MIME-Version: 1.0 References: <20201218023900.E73B82ACBB2B@ary.qy> <3034face-b6fc-0ce2-fa1b-f59210bd6f5b@tana.it> <46339b38-3b24-bcb7-5e73-8a97038ed69@taugh.com> <3997c81d-3b30-0823-a752-fb1d60a44593@tana.it> <74a5c37-19a6-6f6f-a51d-6e5cca5b29e8@taugh.com> <01RTICXKLL3E0085YQ@mauve.mrochek.com> <8813331f-f5e4-faa5-c6d-11212fc25797@taugh.com> <5d150251-427c-5c44-a0c3-ad2e7f24b692@tana.it> <01RTP8I70EYI004QVR@mauve.mrochek.com> <6a4a11ea-fae2-81f5-ce5f-fbd4bc1d41e2@taugh.com> In-Reply-To: <6a4a11ea-fae2-81f5-ce5f-fbd4bc1d41e2@taugh.com> From: Tim Wicinski Date: Mon, 28 Dec 2020 13:00:12 -0500 Message-ID: To: John R Levine Cc: Ned Freed , IETF DMARC WG Content-Type: multipart/alternative; boundary="00000000000052eb2405b78a0c3d" Archived-At: Subject: Re: [dmarc-ietf] reporting documents, Ticket #55 - Clarify legal and privacy implications of failure reports X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Dec 2020 18:00:26 -0000 --00000000000052eb2405b78a0c3d Content-Type: text/plain; charset="UTF-8" I will admit my memory can get pretty hazy, but I agree with Mr Levine - I remember splitting out reporting, but only as one document. The Working Group can always make a compelling case to change this tim On Mon, Dec 28, 2020 at 12:06 PM John R Levine wrote: > On Mon, 28 Dec 2020, Ned Freed wrote: > > I'm not ethusiastic about the split, but if that's what people want then > so be > > it. I will say that my experience has been that doing so is usually more > work > > and provides less benefit than you'd expect. > > I recall agreeing to split out all of the reporting into a separate draft, > which makes some sense so the two parts can proceed separately, but not > further splitting aggregate and failure reports. > > Regards, > John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY > Please consider the environment before reading this e-mail. https://jl.ly > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > --00000000000052eb2405b78a0c3d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

I= will admit my memory can get pretty hazy, but I agree with Mr Levine - I r= emember splitting out reporting,
but only as one document.=C2=A0 =C2=A0

The Working Group can al= ways make a compelling case to change this

tim


<= div dir=3D"ltr" class=3D"gmail_attr">On Mon, Dec 28, 2020 at 12:06 PM John = R Levine <johnl@taugh.com> wro= te:
On Mon, 28 D= ec 2020, Ned Freed wrote:
> I'm not ethusiastic about the split, but if that's what people= want then so be
> it. I will say that my experience has been that doing so is usually mo= re work
> and provides less benefit than you'd expect.

I recall agreeing to split out all of the reporting into a separate draft, =
which makes some sense so the two parts can proceed separately, but not further splitting aggregate and failure reports.

Regards,
John Levine, johnl@tau= gh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
--00000000000052eb2405b78a0c3d-- From nobody Mon Dec 28 10:06: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 E301B3A0CD6 for ; Mon, 28 Dec 2020 10:06:11 -0800 (PST) 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 BMm_nNPNXPo5 for ; Mon, 28 Dec 2020 10:06:10 -0800 (PST) Received: from mail-vk1-xa29.google.com (mail-vk1-xa29.google.com [IPv6:2607:f8b0:4864:20::a29]) (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 E65743A0CD5 for ; Mon, 28 Dec 2020 10:06:09 -0800 (PST) Received: by mail-vk1-xa29.google.com with SMTP id k9so2468730vke.4 for ; Mon, 28 Dec 2020 10:06:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=UdRH7LIy0iqwJ01K93GUZa9PdJlGRmP8rIUaxoeT8NI=; b=X2OuPn9A/+XdDEsK+6iA9LdyK+2rM31lUqzaRAeoV6h/vt61WYqlktfp38H7xA6iz+ gJG5xFAui+4tGjlfOT2ziz6jQaU+jhCFrgcFndAsASUHswh/EVP4odhR/91rCgHPIOso F8WU7XREKiB5JkeC0QPBPxq9so5zbKsQTKOPcpEcwziMHvlpPk1B4DaEvJkiP+3qnHMj QhFM7QEDo4gucpzvwzj3zYGDr37gtp1G6SNZVViBwK/tCx8tX5wrS4GJbOghfyXE4GLm Nz8tI4RoTzRaL80CODJYrt1MQd2Uj6b5vYG8ca/QOBnero5M2NnzXVIKeTdLwfNLlxOZ pLcw== 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=UdRH7LIy0iqwJ01K93GUZa9PdJlGRmP8rIUaxoeT8NI=; b=KdQAARubhGAb3ohwo/6ESR6swnKIgm1pJm5lapgcb7sMgSsOGfLL39hzEP6cMp5zKe nHEEG8o1uhsIhH9NC34jF8z7FfvbWrXuOzBpSoRJOOKNew4zEPLGEkWYwRdJgjUf7P9b U6fWUbhD3ROLJkB4hOCa5aYgIK5+AP0dUrfv0SkqX2RDjJeRPQNFx6F6iP34oZMzaBCM tNHkzsuNnaH7BHJYHGgTTqE7EFgfgaIjvrGq+uWdFC5rutqqMybaLKfOnBwpnl3JddPY TQmcSPQyXjnGNkfk0D+9hN1TTQZHfK4HbNNWpzmYsET8O8XHZpxWZ3jTECnQM90b8PKD gpyQ== X-Gm-Message-State: AOAM532cytcjRJFXbKZ7oYA6Z/b1zA3ffvp4mydy6sUbcmOrHTBA6Kv9 s7Q+KI/XA7WfPNVovT+7HqxIfSLuvqqyTTnDe5fze2zS1SA= X-Google-Smtp-Source: ABdhPJzpvHrFg/+B3Nnaq9jGtfm9OI3s98B7JRPBklCjOXkX1o5y8LQFhpiR8QCB+S13kNny5bwVmNHwA6mS4TXZUSY= X-Received: by 2002:a1f:182:: with SMTP id 124mr29582497vkb.4.1609178768348; Mon, 28 Dec 2020 10:06:08 -0800 (PST) MIME-Version: 1.0 References: <20201218023900.E73B82ACBB2B@ary.qy> <3034face-b6fc-0ce2-fa1b-f59210bd6f5b@tana.it> <46339b38-3b24-bcb7-5e73-8a97038ed69@taugh.com> <3997c81d-3b30-0823-a752-fb1d60a44593@tana.it> <74a5c37-19a6-6f6f-a51d-6e5cca5b29e8@taugh.com> <01RTICXKLL3E0085YQ@mauve.mrochek.com> <8813331f-f5e4-faa5-c6d-11212fc25797@taugh.com> <5d150251-427c-5c44-a0c3-ad2e7f24b692@tana.it> <01RTP8I70EYI004QVR@mauve.mrochek.com> <6a4a11ea-fae2-81f5-ce5f-fbd4bc1d41e2@taugh.com> In-Reply-To: From: Seth Blank Date: Mon, 28 Dec 2020 10:05:57 -0800 Message-ID: To: IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000de332305b78a2068" Archived-At: Subject: Re: [dmarc-ietf] reporting documents, Ticket #55 - Clarify legal and privacy implications of failure reports X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Dec 2020 18:06:12 -0000 --000000000000de332305b78a2068 Content-Type: text/plain; charset="UTF-8" We agreed to split aggregate and failure reporting into different documents, and this split was discussed on the list several times, as well as at IETF 108. The intention was to split apart the key components that realistically get updated in different manners / at different cadences. Aggregate reports and failure reports get used in wholly different manners, have fundamentally different use cases, are implemented in wildly different ways, and have completely different privacy and security considerations. Hence, we agreed they should be split into separate documents, so each can be concise, to the point, and independently updated. Seth, as Chair On Mon, Dec 28, 2020 at 10:00 AM Tim Wicinski wrote: > > I will admit my memory can get pretty hazy, but I agree with Mr Levine - I > remember splitting out reporting, > but only as one document. > > The Working Group can always make a compelling case to change this > > tim > > > On Mon, Dec 28, 2020 at 12:06 PM John R Levine wrote: > >> On Mon, 28 Dec 2020, Ned Freed wrote: >> > I'm not ethusiastic about the split, but if that's what people want >> then so be >> > it. I will say that my experience has been that doing so is usually >> more work >> > and provides less benefit than you'd expect. >> >> I recall agreeing to split out all of the reporting into a separate >> draft, >> which makes some sense so the two parts can proceed separately, but not >> further splitting aggregate and failure reports. >> >> Regards, >> John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY >> Please consider the environment before reading this e-mail. https://jl.ly >> >> _______________________________________________ >> dmarc mailing list >> dmarc@ietf.org >> https://www.ietf.org/mailman/listinfo/dmarc >> > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > -- *Seth Blank* | VP, Standards and New Technologies *e:* seth@valimail.com *p:* 415.273.8818 This email and all data transmitted with it contains confidential and/or proprietary information intended solely for the use of individual(s) authorized to receive it. If you are not an intended and authorized recipient you are hereby notified of any use, disclosure, copying or distribution of the information included in this transmission is prohibited and may be unlawful. Please immediately notify the sender by replying to this email and then delete it from your system. --000000000000de332305b78a2068 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
We agreed to split aggregate and failure reporting into di= fferent documents, and this split was discussed on the list several times, = as well as at IETF 108.

The intention was to split apart= the key components that realistically get updated in different manners / a= t different cadences.

Aggregate=C2=A0reports and f= ailure reports get used in wholly different manners, have fundamentally dif= ferent use cases, are implemented in wildly different ways, and have comple= tely different privacy and security considerations. Hence, we agreed they s= hould be split into separate documents, so each can be concise, to the poin= t, and independently updated.

Seth, as Chair
=

= On Mon, Dec 28, 2020 at 10:00 AM Tim Wicinski <tjw.ietf@gmail.com> wrote:

I will admit my memory can get pretty hazy,= but I agree with Mr Levine - I remember splitting out reporting,
but only as one do= cument.=C2=A0 =C2=A0

The Working Group can always make a compelling case to change this<= /div>

tim

On Mon, = Dec 28, 2020 at 12:06 PM John R Levine <johnl@taugh.com> wrote:
On Mon, 28 Dec 2020, Ned Freed wrote: > I'm not ethusiastic about the split, but if that's what people= want then so be
> it. I will say that my experience has been that doing so is usually mo= re work
> and provides less benefit than you'd expect.

I recall agreeing to split out all of the reporting into a separate draft, =
which makes some sense so the two parts can proceed separately, but not further splitting aggregate and failure reports.

Regards,
John Levine, johnl@tau= gh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

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


--

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


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

--000000000000de332305b78a2068-- From nobody Mon Dec 28 10:17: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 CAE343A0CDC for ; Mon, 28 Dec 2020 10:17:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, 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=mtcc.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 fqqFLg2HsNJu for ; Mon, 28 Dec 2020 10:17:37 -0800 (PST) Received: from mail-pj1-x102d.google.com (mail-pj1-x102d.google.com [IPv6:2607:f8b0:4864:20::102d]) (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 334C83A0CDB for ; Mon, 28 Dec 2020 10:17:36 -0800 (PST) Received: by mail-pj1-x102d.google.com with SMTP id lj6so67466pjb.0 for ; Mon, 28 Dec 2020 10:17:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mtcc.com; s=fluffulence; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=K0txgQpvhy62lE5kccCA6bDldCK5LYB45jaSnuZYvBg=; b=Xesu1xMj5NiVxEgPyV9ihoCOullGxpsCratS5/MQueyaSZ0WmHdjtmBz6alnZj5kBa tL4CVUQ3S0EkPwi60ZLbl5nYrpKrYZyA3D31KBozhJ8FezywAteCpJmsYDlPE9NxidX1 xDQklIUBKSzSoOuKyyje7pqW7jdMPskoZZU9YTbbfF/XlqAhT/4EHDGAt1pdt9NSnUwM F1jHSPhqCCFWW6zuaaIi0Uq+hZu2B1Acq6eDMMM7PB2gvaK6omwWi1EF9k66MbKsQNwP pL8j/aK8J3R05sapCDh9aiZ7sIBdLNLQ+Isg3iRg1vljNsW3Ci32LAmo63YGLW+CG5Vu U/ow== 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=K0txgQpvhy62lE5kccCA6bDldCK5LYB45jaSnuZYvBg=; b=g2OgJkc3uliCJf5xq53pxsApN3rVaCfCtHt7b7KiJ39e9wC9D6kOveW8ZNhyaIkVzT DQBLQOEGYIOsZ7MS1C5GVvTRh1KzJ5YHHbXwASaK0aZw1FHvglFcAGkEdcO4gcWw7ltS DFBJHiqC62mw9Lm269eqW/WSaku6W2kT4ibjXHlZqKyBEFw1MJQq485sHHE7f+NohRuL GxHM1XRhRu17JHWnWSSgswF5fF4TjgKT2T5Lv4HbgNvkIfmp72EhkQvmuYfV8WRs404i 57cdujhpWtXpoV2yrLH6A1kCsvxWVqdQylFB90li5uEGoEuOLxodDQpsJX1u6K3pwWQT I+rw== X-Gm-Message-State: AOAM532JCS4slgWVxfpj6ixjkzPntmV8BHv+XouBxVHu4Z0ukjouOoUz Kn6aGw7gT+dds+e6ZGjNGdV91uH4zHgi1Q== X-Google-Smtp-Source: ABdhPJy4cMYqI3nIf7CEkCVSdwc993KXxg6fLVu5hkBSVQt0b3+KliqPwrucl5y6CAXMgMb9a+3EQQ== X-Received: by 2002:a17:90a:6a48:: with SMTP id d8mr135830pjm.130.1609179456201; Mon, 28 Dec 2020 10:17:36 -0800 (PST) Received: from mike-mac.lan ([107.182.37.0]) by smtp.gmail.com with ESMTPSA id na6sm75436pjb.12.2020.12.28.10.17.35 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 28 Dec 2020 10:17:35 -0800 (PST) To: dmarc@ietf.org References: <20201218023900.E73B82ACBB2B@ary.qy> <74a5c37-19a6-6f6f-a51d-6e5cca5b29e8@taugh.com> <01RTICXKLL3E0085YQ@mauve.mrochek.com> <8813331f-f5e4-faa5-c6d-11212fc25797@taugh.com> <5d150251-427c-5c44-a0c3-ad2e7f24b692@tana.it> <01RTP8I70EYI004QVR@mauve.mrochek.com> <6a4a11ea-fae2-81f5-ce5f-fbd4bc1d41e2@taugh.com> From: Michael Thomas Message-ID: <22d97bde-22c3-ef30-c93a-ec89951ab5be@mtcc.com> Date: Mon, 28 Dec 2020 10:17:34 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.6.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] reporting documents, Ticket #55 - Clarify legal and privacy implications of failure reports X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Dec 2020 18:17:39 -0000 On 12/28/20 10:05 AM, Seth Blank wrote: > We agreed to split aggregate and failure reporting into different > documents, and this split was discussed on the list several times, as > well as at IETF 108. > > The intention was to split apart the key components that realistically > get updated in different manners / at different cadences. > > Aggregate reports and failure reports get used in wholly different > manners, have fundamentally different use cases, are implemented in > wildly different ways, and have completely different privacy and > security considerations. Hence, we agreed they should be split into > separate documents, so each can be concise, to the point, and > independently updated. > Does that mean all of the reporting? So that DMARC is really ADSP-bis? The reporting is clearly a completely separate protocol from the policy mechanism, and is far more likely to mutate than the base policy mechanism which has changed very little from ADSP. I mean, as far as I can tell the main change from ADSP is to include spf too. Mike From nobody Mon Dec 28 10:49: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 C362E3A0CF5 for ; Mon, 28 Dec 2020 10:49:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.85 X-Spam-Level: X-Spam-Status: No, score=-1.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iecc.com header.b=FYNhju4u; dkim=pass (2048-bit key) header.d=taugh.com header.b=Tsib9WQT Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LPAJfQsj0lFo for ; Mon, 28 Dec 2020 10:49:20 -0800 (PST) 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 4FEB33A0CF4 for ; Mon, 28 Dec 2020 10:49:19 -0800 (PST) Received: (qmail 2463 invoked from network); 28 Dec 2020 18:49: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:cleverness; s=99d.5fea28ad.k2012; bh=xcAdg5TjHBiMMr5iFVdSatsRo+83LfQIAQSHwvKXbL8=; b=FYNhju4uvZqmbaiUg9lSgWZgMQ5mhnracnSuFNA7A/QVtnVdPFXTXskMZDRk5ZjmR12MiHI/t/mrJ0SmkDWXbZWNE3Ohp6okFzJKCkQpw3LyKGp3mfKUBhLjEjxz+ZqvfoIZKoJGJo9cBUNypXYkierWmZjxyaaU8KydCgxycUYJZ3znWifLHLXBhlLdFbkLuNkAB3B/ly5U24XXHJrlst7hCBRQmp5WQDArGZfn1XJmxK0MvfxIq9owaKn/AsjTP2Ng/JJD6LJxWV4oY5mvWfpA0OhzOSCnWtQ3vyQQm5KlR+eWozrm8RXS2JppkPV4garbHSq8XBWdcJDtDauHNg== DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=99d.5fea28ad.k2012; bh=xcAdg5TjHBiMMr5iFVdSatsRo+83LfQIAQSHwvKXbL8=; b=Tsib9WQToebYqMfVeUaOY+YrgAz3AiogvnDIiJE5TL/KiH9qfiVV3lgKSY8i3VUn57rPktDFdH3Yaa2Rc4psnechjvV1HdjbgpWcRikwoEDfvYApaELX1vUFNJhKBwXP2QCqVAXQXC+wGtUFgH+UsxBeKx9ro5+BtucXcciIx7pTmOo6rsODrU/EIWwaBurdpJMVFDKW4W/Kb1hj3JGW6uIpqR1NXgSG0JY21grY6wgwjXCQfZqVnepLV+XxQ320laBhwfgPVxqEfiTT1q/KMx2oT0VBIa/vjgBeW4AZwojHToZSIjquHvfh/w49wGpfpxMiauuFKlOPGyVyziajog== 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 Dec 2020 18:49:16 -0000 Received: by ary.qy (Postfix, from userid 501) id D190730262B7; Mon, 28 Dec 2020 13:49:15 -0500 (EST) Date: 28 Dec 2020 13:49:15 -0500 Message-Id: <20201228184915.D190730262B7@ary.qy> From: "John Levine" To: dmarc@ietf.org Cc: seth@valimail.com In-Reply-To: Organization: Taughannock Networks X-Headerized: yes Cleverness: minimal Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] reporting documents, Ticket #55 - Clarify legal and privacy implications of failure reports X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Dec 2020 18:49:22 -0000 In article you write: >-=-=-=-=-=- >Aggregate reports and failure reports get used in wholly different manners, >have fundamentally different use cases, are implemented in wildly different >ways, and have completely different privacy and security considerations. All true, but the actual specs overlap quite a lot. For example, where does section 7.1 about verifying external destinations go? If the answer is that it's copied into two documents, that is bad. I think we've seen that for failure reporting there is nothing to change beyond updating the privacy considerations, so leaving all the reporting in one document is unlikely to cause schedule problems. R's, John From nobody Mon Dec 28 10:52: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 6B1803A0CFE for ; Mon, 28 Dec 2020 10:52:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.85 X-Spam-Level: X-Spam-Status: No, score=-1.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iecc.com header.b=Oz2ngPLv; dkim=pass (2048-bit key) header.d=taugh.com header.b=FqrgqmFp Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mr_F7JrwLR9D for ; Mon, 28 Dec 2020 10:52:20 -0800 (PST) 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 5ACF83A0CF4 for ; Mon, 28 Dec 2020 10:52:20 -0800 (PST) Received: (qmail 3361 invoked from network); 28 Dec 2020 18:52:19 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=d1e.5fea2963.k2012; bh=+GlkbCHkp+9P42yW9ckRwwhc8oJyyLdqNSFnoMWEMZY=; b=Oz2ngPLvcRp68gvlkB9NBsUu1ghRnN/H0J3qAFwcbjAX4KBBG+4sZkztc3Zx0BkjlGzJYTBWxtwhBmiNndCrMccxkiyjnlKx9VIzSiRvBNym9xH7cTHjpsDDJnPZgYWv50IG3OlRsBRPyGuL8AK8x2YJJjUgKYFUqRag3auy4ZdjqZoQe2R+7MePIBLPhc6n4PW4mzNpa+k5HAZX5qNEG61I0a1/KVGxuRISUFXDs7FpEw0AQakomlKjs5HC7YNwWQaOAH2BXeKXny6udMftKXPbTPPvXxmsLGE96DgK3JGQrC4Po90Pa+EyEKCciwdnxOoilIB2CJGBYCh2qkv9Lw== DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=d1e.5fea2963.k2012; bh=+GlkbCHkp+9P42yW9ckRwwhc8oJyyLdqNSFnoMWEMZY=; b=FqrgqmFpkqDq7le1jbkzP/+oKxt+iRChLmQqhLB8K0NHKfwJF6faxUilIRn9TFr3BkCcg2W9j80oP/jNvrN3fEWqhmEGxhzhH0oN0v7rX9HuI7VdJS/gjD2wNRopGHWLdbEvcZ+OkLFCsBOfk6wo9KFg5a6nlY7Eo+6ygBupicFGxZWzr7pUYkKrE3FoYjRnkru8iVy8TTtP46/aIi5I2lnuJcIeo0Soax1OCsgEzFSxnThtUaq5Yp6AioklXpZxZd3fKMB2NbnL/wZwYD4YBJpArYMsyK42UlrL4+aSjIBdJxH6FWyrhrWWhmEJ6JNbUDc6Yx7PO2FWqfsoizBx1Q== 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 Dec 2020 18:52:18 -0000 Received: by ary.qy (Postfix, from userid 501) id 44EB430262F0; Mon, 28 Dec 2020 13:52:18 -0500 (EST) Date: 28 Dec 2020 13:52:18 -0500 Message-Id: <20201228185218.44EB430262F0@ary.qy> From: "John Levine" To: dmarc@ietf.org Cc: todd.herr@valimail.com In-Reply-To: Organization: Taughannock Networks X-Headerized: yes Cleverness: minimal Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] Ticket #55 - Clarify legal and privacy implications of failure reports X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Dec 2020 18:52:22 -0000 In article you write: >Is it not also important to note that the recipient of the failure report >(the domain owner) may not be the originator of the failed message, and >that fact should also weigh into the consideration of deciding whether to >generate such reports? The exact same issue applies to aggregate reports which can leak a fair amount of PII from domains with modest amounts of traffic so you can guess who sent what. See my prior message about the county government. R's, John >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. Somehow this boilerplate seems especially ironic. From nobody Mon Dec 28 11:31: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 288D93A0D73 for ; Mon, 28 Dec 2020 11:31:42 -0800 (PST) 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=fTZAHNLS; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=0Gi/8sez Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v4t22sltGfdh for ; Mon, 28 Dec 2020 11:31:40 -0800 (PST) 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 915193A0E17 for ; Mon, 28 Dec 2020 11:31:36 -0800 (PST) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha256; c=simple/relaxed; l=3004; t=1609183889; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=jaK365znsmAIQfyORR63JRF7UhN2 upq9FPgPRwjMcw0=; b=fTZAHNLSjogJy2qw8jTNy1kSfnTd7UAm5Z+Ph3sofMOP DOKNQy4HNMII+bd0wuX9cUosbjikkzmm62fCPlZNNYdWfBkHwqan7DRSWZHDv8wO DLnw4gJauviSzH5INO6rkHFuKrZhg0V+gqtC5KxPCAkKu/L6wwql2tmLdHasypY= Received: by mail.winserver.com (Wildcat! SMTP Router v8.0.454.10) for dmarc@ietf.org; Mon, 28 Dec 2020 14:31:29 -0500 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 2623954229.16935.3272; Mon, 28 Dec 2020 14:31:28 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=3004; t=1609183519; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=jaK365z nsmAIQfyORR63JRF7UhN2upq9FPgPRwjMcw0=; b=0Gi/8sezFmqf8O6twzViOxg RX2elTlTUeVT79ccLIKSom4l7vniAc8uguC+23Lw4xwKu0onQ8dBoUEQKvv7KpEQ GN+po+HOMjN5tkeWljAsRh0RlgceLlVAGsC+hQ1yMv2jyoSuJ+loNfXQ4o01+1fG x6WqRv1fL6L8kaa445Qk= Received: by beta.winserver.com (Wildcat! SMTP Router v8.0.454.10) for dmarc@ietf.org; Mon, 28 Dec 2020 14:25:19 -0500 Received: from [192.168.1.68] ([75.26.216.248]) by beta.winserver.com (Wildcat! SMTP v8.0.454.10) with ESMTP id 2490824220.1.17296; Mon, 28 Dec 2020 14:25:19 -0500 Message-ID: <5FEA328F.9010701@isdg.net> Date: Mon, 28 Dec 2020 14:31:27 -0500 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: <20201218023900.E73B82ACBB2B@ary.qy> <01RTICXKLL3E0085YQ@mauve.mrochek.com> <8813331f-f5e4-faa5-c6d-11212fc25797@taugh.com> <5d150251-427c-5c44-a0c3-ad2e7f24b692@tana.it> <01RTP8I70EYI004QVR@mauve.mrochek.com> <6a4a11ea-fae2-81f5-ce5f-fbd4bc1d41e2@taugh.com> <22d97bde-22c3-ef30-c93a-ec89951ab5be@mtcc.com> In-Reply-To: <22d97bde-22c3-ef30-c93a-ec89951ab5be@mtcc.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] reporting documents, Ticket #55 - Clarify legal and privacy implications of failure reports X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Dec 2020 19:31:48 -0000 On 12/28/2020 1:17 PM, Michael Thomas wrote: > > On 12/28/20 10:05 AM, Seth Blank wrote: >> We agreed to split aggregate and failure reporting into different >> documents, and this split was discussed on the list several times, >> as well as at IETF 108. >> >> The intention was to split apart the key components that >> realistically get updated in different manners / at different cadences. >> >> Aggregate reports and failure reports get used in wholly different >> manners, have fundamentally different use cases, are implemented in >> wildly different ways, and have completely different privacy and >> security considerations. Hence, we agreed they should be split into >> separate documents, so each can be concise, to the point, and >> independently updated. >> > > Does that mean all of the reporting? So that DMARC is really ADSP-bis? When Seymour Cray was asked by his engineers building the Cray super computer, what primary language should they use for the new concept of Vectorization computing, Seymour responded; "I don't care what language we use ... just call it FORTRAN!" It's marketing now, folks. It was what academia was teaching and industry engineers were using at the time. Lets just get the DKIM-POLICY model done and call it DMARC. I really don't care because the basic fundamental concept has been established and to me, that is the most significant gain we have here - the DKIM-POLICY DNS LOOKUP concept has traction. Yes, functionally, they were all the same, SSP, ADSP, DSAP and DMARC, from the basic LMAP "Lightweight Mail Authorization Protocol" concept of using an author domain for a DKIM-POLICY DNS lookup model. DMARC is the latest with a different syntax language that has gained traction. I support DMARC for that only reason -- its about TIME!! I rather we define the protocol DKIM-POLICY Model because we already have a DKIM-TRUST model in the standard. Nonetheless, now we can piggy-back off the _dmarc.example.com DNS lookup rather than _adsp._domainkey.example.com. All the same concept, therefore all the same problems. Lets get DMARC done as a basic-lookup protocol and begin adding more to it related to 3rd party authorization protocols which can piggy-back of the DNS call. Reporting should of always been a separate consideration. PS: Consider how many DNS lookups an all-things SMTP receiver does for port 25, non-authenticated/Authorized connections. For wcSMTP: At connection: IP Geo Location Filter IP DNS RBL At SMTP before DATA Maybe EHLO domain DNS matching check Maybe EHLO domain SPF check Maybe MAIL FROM SPF check Maybe MAIL FROM Call Back Verifier (MX) At SMTP DATA if it gets this far: Maybe DKIM check Maybe ADSP 5322.From check Maybe DMARC 5322.From check Maybe ATPS 5322.From check Maybe VBR 5322.From check Overall, there are a lot of calls today per SMTP session. -- Hector Santos, https://secure.santronics.com https://twitter.com/hectorsantos From nobody Mon Dec 28 12: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 335183A0D70 for ; Mon, 28 Dec 2020 12:13:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.399 X-Spam-Level: X-Spam-Status: No, score=-4.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_MED=-2.3, 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 Oe7T_4nNWZcT for ; Mon, 28 Dec 2020 12:13:53 -0800 (PST) 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 7C6E83A0D6F for ; Mon, 28 Dec 2020 12:13:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1609186429; bh=TYm7uxCX4QQtdh1QpN8q7Thnq7oIxQ6EfRVckrGSATI=; l=798; h=To:References:From:Date:In-Reply-To; b=C5RiL+ZcX01RHEvZEdPHnnALXQ2xy+WShT7JM/68YF7BBiftS6u6EFwvwyPRLLxOB eRBYu4wCuO4Kk/yVmZIcFLS9OiPYo8c/TE85gM7yWmicVwYJ5PVROTGT9bvxLJ/ZKo vD0r5Bwlw+Zgso8qNwG2wJLvJzyzs7aLapzuQVC5ey0JGL1spH0WhlzhCNf4L Authentication-Results: tana.it; auth=pass (details omitted) Original-From: Alessandro Vesely 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.000000005FEA3C7D.00005509; Mon, 28 Dec 2020 21:13:49 +0100 To: dmarc@ietf.org References: <20201218023900.E73B82ACBB2B@ary.qy> <3997c81d-3b30-0823-a752-fb1d60a44593@tana.it> <74a5c37-19a6-6f6f-a51d-6e5cca5b29e8@taugh.com> <01RTICXKLL3E0085YQ@mauve.mrochek.com> <8813331f-f5e4-faa5-c6d-11212fc25797@taugh.com> From: Alessandro Vesely Message-ID: Date: Mon, 28 Dec 2020 21:13:48 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.6.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] Ticket #55 - Clarify legal and privacy implications of failure reports X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Dec 2020 20:13:55 -0000 On Mon 28/Dec/2020 16:48:10 +0100 Todd Herr wrote: > > I am not opposed to the generic warning, but the following sentence in the > proposed warning gives me pause: > > "They are meant to aid domain owners to detect why failures reported > in aggregate form occurred." > > The implication, to me, in that sentence is that the failure report will be > sent to the party that originated the message, How do you derive that? To me, the sentence seems to implicate that failure reports go to the same entity which receives aggregate reports. That's not always going to be true either. The point should be that the authority who decides where either kind of reports go is the same who publishes the public keys. "Domain owners" is meant to indicate such authority. Best Ale -- From nobody Mon Dec 28 13:00: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 EA4643A0DD1 for ; Mon, 28 Dec 2020 13:00:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_PASS=-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 RQWG0gkuL9uo for ; Mon, 28 Dec 2020 13:00:37 -0800 (PST) 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 93DF13A0DCE for ; Mon, 28 Dec 2020 13:00:37 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01RTPKAI8Y40008CBM@mauve.mrochek.com> for dmarc@ietf.org; Mon, 28 Dec 2020 12:55:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mrochek.com; s=201712; t=1609188931; bh=tWhjQrSHhHEsoE7HqH6J0QLP6FP7t2GO0Ro6WNgjNZc=; h=From:Cc:Date:Subject:In-reply-to:References:To:From; b=A42D6bszOEnuWuJov2Wj1piVkBj5xYIu4/NWkLmzgduB6AbX5yInYLpjOb+4OOnvn kxxqrpIUXdpmZTWBygvbGb80cE1295yvFJb92hN6JZQM9lleEL5RCuHExHklRWcH/e J+aZ6P2xk7zYcuGLbiUUyPrnMdqq51vNtnJvA9Js= 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 <01RTJOWYX49S004QVR@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for dmarc@ietf.org; Mon, 28 Dec 2020 12:55:23 -0800 (PST) From: ned+dmarc@mrochek.com Cc: Ned Freed , IETF DMARC WG Message-id: <01RTPKA2X6FS004QVR@mauve.mrochek.com> Date: Mon, 28 Dec 2020 12:41:57 -0800 (PST) In-reply-to: "Your message dated Mon, 28 Dec 2020 12:06:18 -0500" <6a4a11ea-fae2-81f5-ce5f-fbd4bc1d41e2@taugh.com> References: <20201218023900.E73B82ACBB2B@ary.qy> <3034face-b6fc-0ce2-fa1b-f59210bd6f5b@tana.it> <46339b38-3b24-bcb7-5e73-8a97038ed69@taugh.com> <3997c81d-3b30-0823-a752-fb1d60a44593@tana.it> <74a5c37-19a6-6f6f-a51d-6e5cca5b29e8@taugh.com> <01RTICXKLL3E0085YQ@mauve.mrochek.com> <8813331f-f5e4-faa5-c6d-11212fc25797@taugh.com> <5d150251-427c-5c44-a0c3-ad2e7f24b692@tana.it> <01RTP8I70EYI004QVR@mauve.mrochek.com> <6a4a11ea-fae2-81f5-ce5f-fbd4bc1d41e2@taugh.com> To: John R Levine Archived-At: Subject: Re: [dmarc-ietf] reporting documents, Ticket #55 - Clarify legal and privacy implications of failure reports X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Dec 2020 21:00:42 -0000 > On Mon, 28 Dec 2020, Ned Freed wrote: > > I'm not ethusiastic about the split, but if that's what people want then so be > > it. I will say that my experience has been that doing so is usually more work > > and provides less benefit than you'd expect. > I recall agreeing to split out all of the reporting into a separate draft, > which makes some sense so the two parts can proceed separately, but not > further splitting aggregate and failure reports. I was referring to the latter; I thought the reference to the drafts involved made that clear. Sorry for the confusion. The outcome of the split of MIME part one into four parts may offer some limited insight here. IMO splitting message bodies from media types was a sound logical split and ended up being a good thing. The split of conformance criteria from media types, however, was a pretty serious lose - they now tend to get ignored - so much so it's tempting to try and undo it. But the split of media type registration from MIME/email was the real win, so much so that it more than justified the entire activity. The lesson, if there is one, is to go just far enough, but no further. Splitting different reporting types smells a lot like "further" to me. Ned From nobody Mon Dec 28 13:21: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 C9DF03A0DE6 for ; Mon, 28 Dec 2020 13:21:14 -0800 (PST) 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 xlDX45jKcxv7 for ; Mon, 28 Dec 2020 13:21:13 -0800 (PST) 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 D78A53A0DE2 for ; Mon, 28 Dec 2020 13:21:12 -0800 (PST) Received: by mail-qt1-x832.google.com with SMTP id b9so7811479qtr.2 for ; Mon, 28 Dec 2020 13:21:12 -0800 (PST) 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=JpEHC2bKZhO7hHdEav13SpnhDLgt75CByz9nJk7bRzo=; b=YjKxsMYOZkD7ww2ZSuZtgKX69CZLJ0kkAenlizxXTtVaYtAu7rOlbVtxBWlrRQpsmR zzG3jRKlWG6ZCrKMCWXFxNB70xlJqv9syPjBWs8iEHN3igiwGLd5q1GL8+SEZ/6frmEp hL6KhwvJn39ayjurLk4v91jF2cYCcJjGEkax8uRfOhY/lsn8zYdvrczXfhbgZtJioaaZ /PtI13aB1O5uXA5lhFx58hqE3TqrQoD+/JXE7XYrmyfOCbOtLeyPIIfdZ0opqEdRckZi xGRyN6KqmvRLMywURSZsgFiRXmwU+k8I/RrpBGi5RQA4fN+wFLU4DYKhwXcAHijn1Bx1 jZdA== 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=JpEHC2bKZhO7hHdEav13SpnhDLgt75CByz9nJk7bRzo=; b=KzRUEDuPlvslGmQI2mYu5gY1gzHq/VAwu0/Ob+RIo0DUPYlj3dRVNX5QR2ehcsPSUX 1KHNadP5AP6Vz0LEGZ73wuLBNKT40GzJwHxtPevcFCy/l87ePUC75obkLWpGdp2sJPvs EihR2bRBMFKoDZRjMCogsI+SaJw1RellwBl83m8e94T34WcfmJhh8k8u9XlFMKLSj4JA hAWiETjlGCGhV2xVS150nCyjvS3JmeSuSZ29iPGa81ChXejsS1S4zeiesq3OwOYW89L2 RhXoSxUoH0TPywSY9TPyeVGV2KYaXGRGbb/nH0Q6RTFXqmdg/vWi6tI8xYBOpGGweqCm ClqQ== X-Gm-Message-State: AOAM531WD4OTJeKkKTzq0oPVf5cIf0QFz1ZngDeJEupyeqySDcblwlQl STZ7G7HgyGPwmgZUgGde2j045cZsT/MTI0dFcXK3eRaLYpY= X-Google-Smtp-Source: ABdhPJwij3hruay+jhkQyOTdIiH4fH1XulcW2oKc5RMUsdNfo5lsxgA0cNsb8S8Uhck6PKVCvpNt4OySvoq6QoHy6e4= X-Received: by 2002:ac8:6b0a:: with SMTP id w10mr46685415qts.224.1609190471924; Mon, 28 Dec 2020 13:21:11 -0800 (PST) MIME-Version: 1.0 References: <20201218023900.E73B82ACBB2B@ary.qy> <3997c81d-3b30-0823-a752-fb1d60a44593@tana.it> <74a5c37-19a6-6f6f-a51d-6e5cca5b29e8@taugh.com> <01RTICXKLL3E0085YQ@mauve.mrochek.com> <8813331f-f5e4-faa5-c6d-11212fc25797@taugh.com> In-Reply-To: From: Todd Herr Date: Mon, 28 Dec 2020 16:20:55 -0500 Message-ID: To: Alessandro Vesely Cc: IETF DMARC WG Content-Type: multipart/alternative; boundary="00000000000074908805b78cda08" Archived-At: Subject: Re: [dmarc-ietf] Ticket #55 - Clarify legal and privacy implications of failure reports X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Dec 2020 21:21:15 -0000 --00000000000074908805b78cda08 Content-Type: text/plain; charset="UTF-8" On Mon, Dec 28, 2020 at 3:14 PM Alessandro Vesely wrote: > On Mon 28/Dec/2020 16:48:10 +0100 Todd Herr wrote: > > > > I am not opposed to the generic warning, but the following sentence in > the > > proposed warning gives me pause: > > > > "They are meant to aid domain owners to detect why failures reported > > in aggregate form occurred." > > > > The implication, to me, in that sentence is that the failure report will > be > > sent to the party that originated the message, > > > How do you derive that? To me, the sentence seems to implicate that > failure > reports go to the same entity which receives aggregate reports. That's > not > always going to be true either. The point should be that the authority > who > decides where either kind of reports go is the same who publishes the > public > keys. "Domain owners" is meant to indicate such authority. > > Forgive me, as my words weren't clear here. "[Failure reports] are meant to aid domain owners to detect why failures reported in aggregate form occurred" says to me that the idea behind failure reports is to put them in the hands of a party that can address the failures. DMARC validation failures can be caused either due to legitimate mail (i.e., mail originated by or on behalf of the publisher of the DMARC policy, a.k.a., the domain owner) failing authentication checks due to a shortcoming in the authentication practices of the domain owner or some other hiccup that occurs in transit, OR by illegitimate mail (i.e., mail not originated by or on behalf of the domain owner, so mail intended to fraudulently impersonate the domain), specifically the kind of mail that DMARC is purported to be designed to stop. All reports will go to the domain owner, and they should all go to the domain owner, but the domain owner will have no interest in fixing the authentication practices of the illegitimate mail streams identified by failure reports, nor would it have the ability to do so even if it wanted to. I believe at one time long ago there was an idea that a second possible usage for failure reports showing illegitimate mail was to give the domain owner evidence to present to an abuse desk or takedown vendor to get the illegitimate mail cut off at its source, but I don't know that for certain. Without such a use case, failure reports regarding mail that the domain owner didn't cause to be originated are just noise, because there's no action that the domain owner can take. -- *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. --00000000000074908805b78cda08 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Dec 28, 2020 at 3:14 PM Alessandr= o Vesely <vesely@tana.it> wrote= :
On Mon 28/Dec/2020 16:48:10 +0100 Todd Herr wrote:
>
> I am not opposed to the generic warning, but the following sentence in= the
> proposed warning gives me pause:
>
>=C2=A0 =C2=A0 =C2=A0"They are meant to aid domain owners to detect= why failures reported
>=C2=A0 =C2=A0 =C2=A0in aggregate form occurred."
>
> The implication, to me, in that sentence is that the failure report wi= ll be
> sent to the party that originated the message,


How do you derive that?=C2=A0 To me, the sentence seems to implicate that f= ailure
reports go to the same entity which receives aggregate reports.=C2=A0 That&= #39;s not
always going to be true either.=C2=A0 The point should be that the authorit= y who
decides where either kind of reports go is the same who publishes the publi= c
keys.=C2=A0 "Domain owners" is meant to indicate such authority.<= br>

Forgive me, as my words weren't= clear here.

"[Failure reports] are meant to = aid domain owners to detect why failures reported in aggregate form occurre= d" says to me that the idea behind failure reports is to put them in t= he hands of a party that can address the failures.

DMARC validation failures can be caused either due to legitimate mail (i.e= ., mail originated by or on behalf of the publisher of the DMARC policy, a.= k.a., the domain owner) failing authentication checks due to a shortcoming = in the authentication practices of the domain owner or some other hiccup th= at occurs in transit, OR by illegitimate mail (i.e., mail not originated by= or on behalf of the domain owner, so mail intended to fraudulently imperso= nate the domain), specifically the kind of mail that DMARC is purported to = be designed to stop.

All reports will go to the do= main owner, and they should all go to the domain owner, but the domain owne= r will have no interest in fixing the authentication practices of the illeg= itimate mail streams identified by failure reports, nor would it have the a= bility to do so even if it wanted to.=C2=A0

I beli= eve at one time long ago there was an idea that a second possible usage for= failure reports showing illegitimate mail was to give the domain owner evi= dence to present to an abuse desk or takedown vendor to get the illegitimat= e mail cut off at its source, but I don't know that for certain. Withou= t such a use case, failure reports regarding mail that the domain owner did= n't cause to be originated are just noise, because there's no actio= n that the domain owner can take.

--

Todd Herr | Sr. Tec= hnical Program Manager
= p: 703.220.4153
=


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

--00000000000074908805b78cda08-- From nobody Mon Dec 28 14: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 077393A0E5D for ; Mon, 28 Dec 2020 14:16:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.85 X-Spam-Level: X-Spam-Status: No, score=-1.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iecc.com header.b=W2eEiJaU; dkim=pass (2048-bit key) header.d=taugh.com header.b=cqXoU62M Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d-iOtK5kbn2v for ; Mon, 28 Dec 2020 14:16:23 -0800 (PST) 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 53D4D3A0E5B for ; Mon, 28 Dec 2020 14:16:22 -0800 (PST) Received: (qmail 61418 invoked from network); 28 Dec 2020 22:16:21 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=efe8.5fea5935.k2012; bh=NGcIRY2uIkNaz4h6+HKzRkCC32jqmHp3BcP9XiKaiCg=; b=W2eEiJaU+XvPV8W2U0jM9F9uAp3Tue9pCLbBmET651gf7BCsApauwP9A+SP+DrM+s1ZU0nVYNSm6gI0JS9G9Q2WRnIvOjwU7GLRUMmFGnTv+rKVLVufTrqRl8IVgjl1YL00WgEyC9rPBP+RvARGoXDyfe6zvfJsQ7bi///kw6zWqzONrn+OWGFctxIcDjtt3HNxGNvH9AuGId1deeEjzV63ipwi2mPmH9R17LX83w2R66a3VTGLEXeYaryUXp+FMM97R+nu/G1DNh2GV+C4A+GJ4brSmCX+PydGKLKi0z07YdR7rL2okk2AgLS85Gwf6wu7i+J8gCPOBqlRDSmeWmw== DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=efe8.5fea5935.k2012; bh=NGcIRY2uIkNaz4h6+HKzRkCC32jqmHp3BcP9XiKaiCg=; b=cqXoU62MEO0gfet+yfqHnwizKJNSyShU1Bfvqgv5S+R9KTKSGiQDVirXZgYtnoKqS7iSx/OkDonpV9mBZzBNGwYUqUXpfRhkua2Sj7uF0ZLtWfkxhD4GnBVEwlIAa9QMDIPtxUTq/TsDE/3vTZnixpreq9sjjPCPPp7sxjZhxnV5g0oSpPa02sxUhToaTVfdESldlsUYcB9wSUPbCvCwp/M6Jazm2Ctt8oyWn2v5Vh17a1n0+0S6eUuKkI9SCv9JM3kr9EjsO+iQ2ytYOoW639GqiGzMEXmQdJxpyc69qoD5CrTUa8xKGuU7SWab4ujDY7+9Z7u5Zn+PzWZwq96t6w== 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 Dec 2020 22:16:21 -0000 Received: by ary.qy (Postfix, from userid 501) id F0C1E3027F77; Mon, 28 Dec 2020 17:16:20 -0500 (EST) Date: 28 Dec 2020 17:16:20 -0500 Message-Id: <20201228221620.F0C1E3027F77@ary.qy> From: "John Levine" To: dmarc@ietf.org Cc: todd.herr@valimail.com In-Reply-To: Organization: Taughannock Networks X-Headerized: yes Cleverness: minimal Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] Ticket #55 - Clarify legal and privacy implications of failure reports X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Dec 2020 22:16:25 -0000 In article you write: >I believe at one time long ago there was an idea that a second possible >usage for failure reports showing illegitimate mail was to give the domain >owner evidence to present to an abuse desk or takedown vendor to get the >illegitimate mail cut off at its source, but I don't know that for certain. We did think of that, but at least in my experience all of the failure reports that aren't legit messages handle were random forgeries from Chinese networks where the spammers were just taking addresses from their spam lists. Perhaps if my name were Paypal I'd see some targeted fakery but it's not my impression that kind of faked mail is sent from fixed sources. >Without such a use case, failure reports regarding mail that the domain >owner didn't cause to be originated are just noise, because there's no >action that the domain owner can take. Yup. Still don't think failure reports need a separate document. R's, John From nobody Mon Dec 28 23:04: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 6C6343A10CB for ; Mon, 28 Dec 2020 23:04:00 -0800 (PST) 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 vDRwwRReWoJZ for ; Mon, 28 Dec 2020 23:03:59 -0800 (PST) Received: from mail-vs1-xe31.google.com (mail-vs1-xe31.google.com [IPv6:2607:f8b0:4864:20::e31]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 279F83A1034 for ; Mon, 28 Dec 2020 23:03:59 -0800 (PST) Received: by mail-vs1-xe31.google.com with SMTP id q10so6626487vsr.13 for ; Mon, 28 Dec 2020 23:03:58 -0800 (PST) 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=LPL3TaaxIFabFOAu/B1G4ZchVlI05uDrPGRJuyR3xD0=; b=bABLbEDq4Z4TkNocAZxaDIdn2pajpgwZ39OeARYhyQlc3AEFYzLHkc15Ev5MYEOS3a v6YGJ72WRF1l1QUqXd4GNfU+wDO5s3Uwvvtj2wSDjMMFMrMaBqQlodn+NvN0Gz8eXR+A 7tWa1SIYWUkoCeOMpBmqRt/MAt0DaTAIQaGTkGNjNM4b5TmnvcUwGzuZ3R/ehpiS3Cme OHWkCjgqDi3chJDQ+gCNcyjKloYXBhku+LRS7ruJOE/JAXGnJLFREiX4NptEyI+0Jy+K xmIfn2F0y2iEvw3/PZVkCNcVeqElj3R3DRwv9XdzOOMG6hiaQrdgNCOeTv3biKCwSLEG wnvw== 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=LPL3TaaxIFabFOAu/B1G4ZchVlI05uDrPGRJuyR3xD0=; b=t1SEZfN1r+TATDO2wcKLam5KUodAgyCaERPZE9yseGNhmYgIhOmuezBFYa03xhAhY/ 4lgwKVl52+TEIOKLhDkePl0v+U6HruRnnBzhoi1CqSnSBoNoq7BaACV4kuQeJs9R6XR2 1VcJPZ8McPSzB2R1wlLdgHan3ct2otEeCLlvdZ3cj4zTLPZJ0D0cB8e/tsIke5wwCMqt wd9sdgAtBn5hw64oLcAibKSW85t0X5R0lDZufzo0UHBdYbugUfc8RkHj+ZJuQytZ2HC/ LbVhW4rCOD70KUWNTp6+IjWd+nOhJ7zEQS5Bzb4V/XAOLSRV3fnpd1BuBZfQvfJpGDK1 gFLw== X-Gm-Message-State: AOAM532rk5vRwxm9mQsIgAh/8R9gPqj5iKoOWlLkP5sSodZLws8Db0su m5TMkx3l8nTHqVJNSqGpTxpHR5w2GrOhIkD362U= X-Google-Smtp-Source: ABdhPJzt3pM/cfyHL3mvBQgslwfN2MIPb4hilhlNpTDP8cOg7XB6TRPflxX6yYnt7isk4oAI7v5G59w+P1j1pcZX/+k= X-Received: by 2002:a67:fb46:: with SMTP id e6mr30854887vsr.40.1609225437952; Mon, 28 Dec 2020 23:03:57 -0800 (PST) MIME-Version: 1.0 References: <20201218023900.E73B82ACBB2B@ary.qy> <3034face-b6fc-0ce2-fa1b-f59210bd6f5b@tana.it> <46339b38-3b24-bcb7-5e73-8a97038ed69@taugh.com> <3997c81d-3b30-0823-a752-fb1d60a44593@tana.it> <74a5c37-19a6-6f6f-a51d-6e5cca5b29e8@taugh.com> <01RTICXKLL3E0085YQ@mauve.mrochek.com> <8813331f-f5e4-faa5-c6d-11212fc25797@taugh.com> <5d150251-427c-5c44-a0c3-ad2e7f24b692@tana.it> <01RTP8I70EYI004QVR@mauve.mrochek.com> In-Reply-To: <01RTP8I70EYI004QVR@mauve.mrochek.com> From: "Murray S. Kucherawy" Date: Mon, 28 Dec 2020 23:03:46 -0800 Message-ID: To: Ned Freed Cc: Alessandro Vesely , Tim Wicinski , IETF DMARC WG , John R Levine Content-Type: multipart/alternative; boundary="00000000000097be1f05b794fecb" Archived-At: Subject: Re: [dmarc-ietf] Ticket #55 - Clarify legal and privacy implications of failure reports X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Dec 2020 07:04:01 -0000 --00000000000097be1f05b794fecb Content-Type: text/plain; charset="UTF-8" On Mon, Dec 28, 2020 at 7:23 AM wrote: > P.S. I hadn't looked at RFC 6589 before, and I have to say I find its > standards-track status to be nothing short of astonishing. How on earth do > you > assess interoperability? > With the benefit of hindsight, that's a great question. I'd have been happy with Informational. Indeed, the IESG evaluation record shows several ADs brought that up, but none of them insisted, and thus it didn't get changed. -MSK --00000000000097be1f05b794fecb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Dec 28, 2020 at 7:23 AM <ned+dmarc@mrochek.com> wrote:<= br>
P.S. I hadn't looked at RFC 6589 before, and I=C2=A0 have to= say I find its
standards-track status to be nothing short of astonishing. How on earth do = you
assess interoperability?

With the benef= it of hindsight, that's a great question.=C2=A0 I'd have been happy= with Informational.=C2=A0 Indeed, the IESG evaluation record shows several= ADs brought that up, but none of them insisted, and thus it didn't get= changed.

-MSK
--00000000000097be1f05b794fecb-- From nobody Tue Dec 29 01:33: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 5CA763A1175 for ; Tue, 29 Dec 2020 01:33:38 -0800 (PST) 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, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 SSxwy49qWeIw for ; Tue, 29 Dec 2020 01:33:35 -0800 (PST) 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 137DF3A1107 for ; Tue, 29 Dec 2020 01:33:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1609234410; bh=TAWMA98MkB1GF4skdYngyoqHyHUASCUg3Yiyst7nOfQ=; l=1852; h=To:References:From:Date:In-Reply-To; b=COmSFej0qlFQTDPsqmagnc6H1eZS/zLA12o8R86vOY0BnMW96taNpthf6y4PfRGdI +UN9ar9MgPQdgGsO4vMAOZLHEiRE7m/egsLFGDpZijjhN0tnU9/URD/LQfqzE5AZF+ /HRb9fbtYxajqmW+60gZ5qCOtY6cQwNsbxJDnxqmCIyc9BjYk3b6J93TWCZGL Authentication-Results: tana.it; auth=pass (details omitted) Original-From: Alessandro Vesely 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.000000005FEAF7EA.00005D1B; Tue, 29 Dec 2020 10:33:30 +0100 To: dmarc@ietf.org References: <20201218023900.E73B82ACBB2B@ary.qy> <3034face-b6fc-0ce2-fa1b-f59210bd6f5b@tana.it> <46339b38-3b24-bcb7-5e73-8a97038ed69@taugh.com> <3997c81d-3b30-0823-a752-fb1d60a44593@tana.it> <74a5c37-19a6-6f6f-a51d-6e5cca5b29e8@taugh.com> <01RTICXKLL3E0085YQ@mauve.mrochek.com> <8813331f-f5e4-faa5-c6d-11212fc25797@taugh.com> <5d150251-427c-5c44-a0c3-ad2e7f24b692@tana.it> <01RTP8I70EYI004QVR@mauve.mrochek.com> From: Alessandro Vesely Message-ID: Date: Tue, 29 Dec 2020 10:33:30 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: <01RTP8I70EYI004QVR@mauve.mrochek.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Ticket #55 - Clarify legal and privacy implications of failure reports X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Dec 2020 09:33:38 -0000 On Mon 28/Dec/2020 15:54:24 +0100 ned+dmarc wrote: > >> I still think it'd be a good idea to mention RFC 6590... > > Why? RFC 6590 documents a generic approach to partial information hiding. It > does not specify how to apply this technique to DMARC failure reports, and > doing so effectively requires a careful assessment of what needs to be hidden > and what does not, and that in turn drags in all of the specifics we need to > avoid in a base document of this sort. The failure-reporting draft references RFC6591. The only appearance of the term "redaction" occurs in the 2nd paragraph of Section 4.1: These reports may expose sender and recipient identifiers (e.g., RFC5322.From addresses), and although the [RFC6591] format used for failed-message reporting supports redaction, failed-message reporting is capable of exposing the entire message to the report recipient. RFC6591 doesn't go into a very detailed description. It references RFC6590: For privacy reasons, report generators might need to redact portions of a reported message, such as an identifier or address associated with the end user whose complaint action resulted in the report. A discussion of relevant issues and a suggested method for doing so can be found in [RFC6590]. RFC6590, in turn, avoids the specifics of what exactly needs to be redacted. However, it mentions the local parts of email addresses. > P.S. I hadn't looked at RFC 6589 before, and I have to say I find its > standards-track status to be nothing short of astonishing. How on earth do > you assess interoperability? Maybe it's the ability to relate reports from the same source with one another which makes them manageable. Producers of actionable reports and consumers who react properly can be said to interoperate, can't they? Best Ale -- From nobody Tue Dec 29 01:59: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 040AC3A1323 for ; Tue, 29 Dec 2020 01:59:41 -0800 (PST) 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, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 3eSP7c8Jime8 for ; Tue, 29 Dec 2020 01:59:39 -0800 (PST) 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 1931E3A10EC for ; Tue, 29 Dec 2020 01:59:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1609235972; bh=4BdLQoutCGkq4qxos4adZODOemB1j6ZB0PfTMvUKrH0=; l=1151; h=To:References:From:Date:In-Reply-To; b=BBXIP6Mnf+CYyNy5IrkIToH0uuQb4NQzEJy+kPN9jqJPXW+dw3vquAxO9UuxlX42K bYEBRfB2vF5ab0YBtJ22WwNjrq2gAXZ8kbEVkKsxxgvKz0e5EG6Mxkc4bL2EhlWwM/ I6ZLSpt/p6wgW28iY+3bjZ8uoM5GjVJyM6RffFO9uc+nPwCtQGi8l77SktQyi Authentication-Results: tana.it; auth=pass (details omitted) Original-From: Alessandro Vesely 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.000000005FEAFE04.00005FE7; Tue, 29 Dec 2020 10:59:32 +0100 To: Todd Herr , IETF DMARC WG References: <20201218023900.E73B82ACBB2B@ary.qy> <01RTICXKLL3E0085YQ@mauve.mrochek.com> <8813331f-f5e4-faa5-c6d-11212fc25797@taugh.com> From: Alessandro Vesely Message-ID: <85fed1c6-4792-316c-836d-9a481c5d4964@tana.it> Date: Tue, 29 Dec 2020 10:59:30 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.6.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] Ticket #55 - Clarify legal and privacy implications of failure reports X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Dec 2020 09:59:41 -0000 On Mon 28/Dec/2020 22:20:55 +0100 Todd Herr wrote: > > DMARC validation failures can be caused either due to legitimate mail > (i.e., mail originated by or on behalf of the publisher of the DMARC > policy, a.k.a., the domain owner) failing authentication checks due to a > shortcoming in the authentication practices of the domain owner or some > other hiccup that occurs in transit, OR by illegitimate mail (i.e., mail > not originated by or on behalf of the domain owner, so mail intended to > fraudulently impersonate the domain), specifically the kind of mail that > DMARC is purported to be designed to stop. That kind of analysis seems to be missing from the draft. After some years of experience, we should be able to provide some, I'd hope. If not, we'd better bluntly drop the draft. Personally, I used to receive a few of them. None at all now. The only mention I recall about failure reports was an old article, by Terry Zinc IIRC, where he said they're key for telling abusers from legit operators needing realignment. I don't recall why that info couldn't be derived from the source IPs though. Best Ale -- From nobody Tue Dec 29 06:50: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 9F0493A1412 for ; Tue, 29 Dec 2020 06:50:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, 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=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mtcc.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 vRlWGCkBo6sA for ; Tue, 29 Dec 2020 06:50:53 -0800 (PST) Received: from mail-pg1-x52e.google.com (mail-pg1-x52e.google.com [IPv6:2607:f8b0:4864:20::52e]) (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 831C13A0AFB for ; Tue, 29 Dec 2020 06:50:53 -0800 (PST) Received: by mail-pg1-x52e.google.com with SMTP id i5so9359838pgo.1 for ; Tue, 29 Dec 2020 06:50:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mtcc.com; s=fluffulence; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=6DOe9lxAZnFqqggi80+G4dJRDf5YkzNrCryoqEIdLGo=; b=Q9DsHdzoevPWKaZ13sbJbUPOpO18DTn55kyIUgK0gG7qNz9WrljyYwGgjggeneEYMw 3TWka79JSobr1zs6V9SXhm8Nd2I8zi/v1SzbeoO2tPpAXI3YFklZb1VHlMltFkYfLTGC oYXJ/XA3cUubh7/DXPYeVyMlTiD/Mgry4oPUTJ4rAzKm6LBzticdkH+Zr8RiqNzUc1eH o73fQZhgOfl4J2LfzjMND5TRQ1/8dUHE/z/AgO33GdaqG/8hgdYMeD04K8H260XymJ7G 7A+YOQaw/VsDndY+0kKGixDBihCx4OltncqIO4mSSPZtBtpP8JR26iiBvSkbvfWp297Y xE/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:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=6DOe9lxAZnFqqggi80+G4dJRDf5YkzNrCryoqEIdLGo=; b=p7AXE1mIwZF5adsSELUgaIr/WgaX2j/vEXPrY20z4/ppyypF+92tyJ9Zi5XPI/qAgM toMCw6QMHW8A31wqM5Q47HKJuO+1JBYadeZj7/r1ECyAZgAELcQakdr41OKISFg/omyf HqF7+wL10iZNTYZqvPmzeXgVoJ8lgvFvMAmyCkqtMihED68cFet+qrbFPx5wS5aU7/6w w3wg1Kj2cKeOVKs4AfM7TBpzOPGaJyhR9+FZfxtN/MFiFO8uPUyK/ghk2uhXrXwGKFH+ QG+qf6z7/IMnvjPx4jAWJX7i8zWUpMrr6yFftyVBKwmjtzq+b27a1rSnJwzwiCNeBTyc 5u5A== X-Gm-Message-State: AOAM532mBVKJISQExgMhXd96UBs/BcnvSMe9GAz6uOmfUU0Bjj2kNRcL hshGGzAty6zGzXhW7dnZlPw+BN/Chk4JMA== X-Google-Smtp-Source: ABdhPJxLfH2fU0hsvmbA3SQSUxgfAGKStaEbJGBV5mphKsdo+6ftMRPVsm6g9VHDQOKecHshfp5Vsw== X-Received: by 2002:a63:1707:: with SMTP id x7mr15480255pgl.266.1609253452342; Tue, 29 Dec 2020 06:50:52 -0800 (PST) Received: from mike-mac.lan ([107.182.37.0]) by smtp.gmail.com with ESMTPSA id gk4sm3308426pjb.57.2020.12.29.06.50.51 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 29 Dec 2020 06:50:51 -0800 (PST) To: dmarc@ietf.org References: <20201218023900.E73B82ACBB2B@ary.qy> <46339b38-3b24-bcb7-5e73-8a97038ed69@taugh.com> <3997c81d-3b30-0823-a752-fb1d60a44593@tana.it> <74a5c37-19a6-6f6f-a51d-6e5cca5b29e8@taugh.com> <01RTICXKLL3E0085YQ@mauve.mrochek.com> <8813331f-f5e4-faa5-c6d-11212fc25797@taugh.com> <5d150251-427c-5c44-a0c3-ad2e7f24b692@tana.it> <01RTP8I70EYI004QVR@mauve.mrochek.com> From: Michael Thomas Message-ID: <7062260e-bcce-8d9f-6a18-d6d932d54a10@mtcc.com> Date: Tue, 29 Dec 2020 06:50:50 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------59F679572491815FD6F908AA" Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] Ticket #55 - Clarify legal and privacy implications of failure reports X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Dec 2020 14:50:55 -0000 This is a multi-part message in MIME format. --------------59F679572491815FD6F908AA Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 12/28/20 11:03 PM, Murray S. Kucherawy wrote: > On Mon, Dec 28, 2020 at 7:23 AM > wrote: > > P.S. I hadn't looked at RFC 6589 before, and I  have to say I find its > standards-track status to be nothing short of astonishing. How on > earth do you > assess interoperability? > > > With the benefit of hindsight, that's a great question. I'd have been > happy with Informational.  Indeed, the IESG evaluation record shows > several ADs brought that up, but none of them insisted, and thus it > didn't get changed. > What I had always expected to happen was, among other things, that MUA's would use it for like a web-like padlock too. At that point you have a protocol consumer. It's sort of disappointing they by and large don't from what I've seen. Hence my question on another thread DMARC fail, with p=none. That seems wrong and would definitely send the wrong signal to the MUA on how to mark it up. Mike, who has now hacked on a thunderbird extension --------------59F679572491815FD6F908AA Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit


On 12/28/20 11:03 PM, Murray S. Kucherawy wrote:
On Mon, Dec 28, 2020 at 7:23 AM <ned+dmarc@mrochek.com> wrote:
P.S. I hadn't looked at RFC 6589 before, and I  have to say I find its
standards-track status to be nothing short of astonishing. How on earth do you
assess interoperability?

With the benefit of hindsight, that's a great question.  I'd have been happy with Informational.  Indeed, the IESG evaluation record shows several ADs brought that up, but none of them insisted, and thus it didn't get changed.

What I had always expected to happen was, among other things, that MUA's would use it for like a web-like padlock too. At that point you have a protocol consumer. It's sort of disappointing they by and large don't from what I've seen. Hence my question on another thread DMARC fail, with p=none. That seems wrong and would definitely send the wrong signal to the MUA on how to mark it up.

Mike, who has now hacked on a thunderbird extension

--------------59F679572491815FD6F908AA-- From nobody Tue Dec 29 07:17: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 3F6FF3A1439 for ; Tue, 29 Dec 2020 07:17:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=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 8gDR3NcNxIpI for ; Tue, 29 Dec 2020 07:17:31 -0800 (PST) Received: from plum.mrochek.com (plum.mrochek.com [172.95.64.195]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F06653A1438 for ; Tue, 29 Dec 2020 07:17:30 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01RTQMLJNAGW00CR7L@mauve.mrochek.com> for dmarc@ietf.org; Tue, 29 Dec 2020 07:12:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mrochek.com; s=201712; t=1609254748; bh=G0/JyKn9Hjzg4QfMKp4D36XPpKxXyzP2A5bSHzX7htI=; h=From:Cc:Date:Subject:In-reply-to:References:To:From; b=YNfj+qaKlGeaZ8Sz1DWVpk5RFGLtc+9cplTheFle+KvWBedXt6iy2eG4IovtkJ01L UG8hgTpQQF+dDKAEeU6V2w3rML65mLxtk9MJj+DClpVOBsdUZ7CLUpiBC7fNzQv7tA rt/CiQMnZaJ8uLnaswaQf8hqmVAApcssJJFma7Gs= 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 <01RTJOWYX49S004QVR@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for dmarc@ietf.org; Tue, 29 Dec 2020 07:12:25 -0800 (PST) From: ned+dmarc@mrochek.com Cc: dmarc@ietf.org Message-id: <01RTQMLIAD88004QVR@mauve.mrochek.com> Date: Tue, 29 Dec 2020 06:55:52 -0800 (PST) In-reply-to: "Your message dated Tue, 29 Dec 2020 10:33:30 +0100" References: <20201218023900.E73B82ACBB2B@ary.qy> <3034face-b6fc-0ce2-fa1b-f59210bd6f5b@tana.it> <46339b38-3b24-bcb7-5e73-8a97038ed69@taugh.com> <3997c81d-3b30-0823-a752-fb1d60a44593@tana.it> <74a5c37-19a6-6f6f-a51d-6e5cca5b29e8@taugh.com> <01RTICXKLL3E0085YQ@mauve.mrochek.com> <8813331f-f5e4-faa5-c6d-11212fc25797@taugh.com> <5d150251-427c-5c44-a0c3-ad2e7f24b692@tana.it> <01RTP8I70EYI004QVR@mauve.mrochek.com> To: Alessandro Vesely Archived-At: Subject: Re: [dmarc-ietf] Ticket #55 - Clarify legal and privacy implications of failure reports X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Dec 2020 15:17:32 -0000 > On Mon 28/Dec/2020 15:54:24 +0100 ned+dmarc wrote: > > > >> I still think it'd be a good idea to mention RFC 6590... > > > > Why? RFC 6590 documents a generic approach to partial information hiding. It > > does not specify how to apply this technique to DMARC failure reports, and > > doing so effectively requires a careful assessment of what needs to be hidden > > and what does not, and that in turn drags in all of the specifics we need to > > avoid in a base document of this sort. > The failure-reporting draft references RFC6591. The only appearance of the > term "redaction" occurs in the 2nd paragraph of Section 4.1: Referencing an approved standards document on failure reporting formats is perfectly reasonable and even necessary. > These reports may expose sender and recipient identifiers (e.g., > RFC5322.From addresses), and although the [RFC6591] format used for > failed-message reporting supports redaction, failed-message reporting > is capable of exposing the entire message to the report recipient. > RFC6591 doesn't go into a very detailed description. It references RFC6590: > For privacy reasons, report generators might need to redact portions > of a reported message, such as an identifier or address associated > with the end user whose complaint action resulted in the report. A > discussion of relevant issues and a suggested method for doing so can > be found in [RFC6590]. > RFC6590, in turn, avoids the specifics of what exactly needs to be redacted. > However, it mentions the local parts of email addresses. If anything this is an even stronger case for not referencing RFC 6590 here - it's unnnecessary because the reference is already in the failure reporting format specification. I also note that RFC 6591 was published in 2012, long before PII became such a contentious issue. Timing can be everything. > > P.S. I hadn't looked at RFC 6589 before, and I have to say I find its > > standards-track status to be nothing short of astonishing. How on earth do > > you assess interoperability? > Maybe it's the ability to relate reports from the same source with one another > which makes them manageable. Producers of actionable reports and consumers who > react properly can be said to interoperate, can't they? Absent agreement on what gets redacted and how? Not even close. RFC 6590 doesn't even pass muster as a BCP, since it describes an overall approach to solving a range of problems and explictly does not recommend a particular practice. This is an informational document, nothing more and nothing less. Ned From nobody Tue Dec 29 08:25:12 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BACD3A145E for ; Tue, 29 Dec 2020 08:25:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, 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=mtcc.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 QR-B3q2T7sOw for ; Tue, 29 Dec 2020 08:25:08 -0800 (PST) Received: from mail-pj1-x1033.google.com (mail-pj1-x1033.google.com [IPv6:2607:f8b0:4864:20::1033]) (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 CF8D03A145C for ; Tue, 29 Dec 2020 08:25:08 -0800 (PST) Received: by mail-pj1-x1033.google.com with SMTP id b5so1751606pjk.2 for ; Tue, 29 Dec 2020 08:25:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mtcc.com; s=fluffulence; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=+fBtLOGv448i2na02s5lHy7T6tqHI+vxVXw/rB7JkXQ=; b=eWfhWFPrfY33qf3+B9nzrI6vB71j7/rnD448+hQQxoKgfQKcTj4m3fXw7DgvB6SD2j hQpfNDyd0XgHwn6Pq9SZA5WZINSTKFvHvAo5HAhmlS3SDOa/foy/B2M0nstn+bV9fccp p0hKw7rIdJplnpQVLyO/Ybaff+R1exr9uDm/C8B/XjSFyer8kvM2uoOqZWbaKs5uNwhD JCgDJwcQmYnT9rOID/PSFFLKWZrNYaLBBGl59fNzoYxp+ulQFvReZ9/J26jVnKO2x7EP KcQNfAbZIJRUfCF+YxVobJsW/BbDyZIpzMtBEb49ZkiH8HzGCM5bb4JX2oFgzjl132B2 H83w== 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=+fBtLOGv448i2na02s5lHy7T6tqHI+vxVXw/rB7JkXQ=; b=KaSRpmcC3w0LDlSyMmw/kx2j+cDFVdvrgsmHNckxZ+/ZqKq6UKO5ars0hNylJBpvQd ZVlEWPYkwbvI5dDl0hgjtahILaXoIAjgmqNWeUiem1VuQuS8PXjp0+Nu0JkKK+zn1Cwb sdTkcerNJbpL9Aa0aTQNBdVJG8Xzjn+XxypvHatLibOgwOSvtZWA2d5je5JLZMMHx6QP JUQwl/2Tuz3xD7XJTS42rF/UgMELsFUh0Pwj7u/kr8hNqUJ1eEfn2mMaFUkC1Z4Bxkiw 9raCmECtktEot6bDRZcEiU2S2ROA6CZZgdkY7ljI6W5IUnX0jvKSHgznhFiCXBcGxl/v cvVw== X-Gm-Message-State: AOAM532ystdMMZZreRVyehPSEy4XcLS/6rK7jXYMjIgW5ZzuCzhg90QX 4uCyjPWy1GISejWz6pEPbufRzz/BOgU0ug== X-Google-Smtp-Source: ABdhPJwBMTyPDVLJU0BiY3NUljUnQrM+444r/dUYrnqm3wnJuBr8oQbi1T6N/ePI/OYEgPIiw2Qxag== X-Received: by 2002:a17:90a:d58c:: with SMTP id v12mr4694662pju.37.1609259107764; Tue, 29 Dec 2020 08:25:07 -0800 (PST) Received: from mike-mac.lan ([107.182.37.0]) by smtp.gmail.com with ESMTPSA id a26sm39454164pgd.64.2020.12.29.08.25.06 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 29 Dec 2020 08:25:07 -0800 (PST) To: dmarc@ietf.org References: <20201218023900.E73B82ACBB2B@ary.qy> <46339b38-3b24-bcb7-5e73-8a97038ed69@taugh.com> <3997c81d-3b30-0823-a752-fb1d60a44593@tana.it> <74a5c37-19a6-6f6f-a51d-6e5cca5b29e8@taugh.com> <01RTICXKLL3E0085YQ@mauve.mrochek.com> <8813331f-f5e4-faa5-c6d-11212fc25797@taugh.com> <5d150251-427c-5c44-a0c3-ad2e7f24b692@tana.it> <01RTP8I70EYI004QVR@mauve.mrochek.com> From: Michael Thomas Message-ID: <8fdba260-7698-19d9-14da-14fbaf751a31@mtcc.com> Date: Tue, 29 Dec 2020 08:25:05 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------B81A59A0EE54E0FCE796DCE1" Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] Ticket #55 - Clarify legal and privacy implications of failure reports X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Dec 2020 16:25:11 -0000 This is a multi-part message in MIME format. --------------B81A59A0EE54E0FCE796DCE1 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 12/28/20 11:03 PM, Murray S. Kucherawy wrote: > On Mon, Dec 28, 2020 at 7:23 AM > wrote: > > P.S. I hadn't looked at RFC 6589 before, and I  have to say I find its > standards-track status to be nothing short of astonishing. How on > earth do you > assess interoperability? > Ned -- rfc6589 is a ipv6 informational doc. which rfc are you actually referring to? Mike --------------B81A59A0EE54E0FCE796DCE1 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit


On 12/28/20 11:03 PM, Murray S. Kucherawy wrote:
On Mon, Dec 28, 2020 at 7:23 AM <ned+dmarc@mrochek.com> wrote:
P.S. I hadn't looked at RFC 6589 before, and I  have to say I find its
standards-track status to be nothing short of astonishing. How on earth do you
assess interoperability?


Ned -- rfc6589 is a ipv6 informational doc. which rfc are you actually referring to?

Mike
--------------B81A59A0EE54E0FCE796DCE1-- From nobody Tue Dec 29 08:38: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 5F6F83A0C6B for ; Tue, 29 Dec 2020 08:38:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, 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=mtcc.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 FTRUEB5bhMqm for ; Tue, 29 Dec 2020 08:38:41 -0800 (PST) Received: from mail-pf1-x432.google.com (mail-pf1-x432.google.com [IPv6:2607:f8b0:4864:20::432]) (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 664063A0C64 for ; Tue, 29 Dec 2020 08:38:41 -0800 (PST) Received: by mail-pf1-x432.google.com with SMTP id h10so7295806pfo.9 for ; Tue, 29 Dec 2020 08:38:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mtcc.com; s=fluffulence; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=yXvPkcmgJkXj4XsZGw9NeolrOkYdiV52U1D3FXTtWZ8=; b=GJ3FEy4xMlqkNrxnZU+b47J/j5j/0BF7fPZczXFdtW9txOXXyrw5OzQv0NUKKvf2DA dBgt2VRqqgDd18Un3eFe+3XpfGFB0ohq20bDtf5irA5QEt/avpEWYUk6V6QL2+ATmlaX nMXwRC+jxC7Zm9vFm8o3ojS6G5utkbvd7bvifIVfBvtjArSuhkOXce5rRQSkdJPho4OX d+hbvZOARJevvGWL4pZepikeUAESdt51Ccr4fnAqK21GfMwc8V4GIm7o6uRQSJa1ij4K sF7lkjBLrgH6k0Yl03WyhoVwLPQjZDEpZzYYK0iAqJLAhwQTe45kT9A8V7cIV7utxaqj iPfQ== 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=yXvPkcmgJkXj4XsZGw9NeolrOkYdiV52U1D3FXTtWZ8=; b=X5ZFaz4yi025VikU9CaSX7iwjUe12JguQcctHValjziKkFke6DyRlTe/7ShQ1qEPB1 ouIlye3VdWANb2xed6HpGA+EDHiVAHvZAF+sM3axnQg4eoC1ZnIGlmk+luPowA8hGoCs frisQjHeTTdYKbDkXTGUL0YcnGgS3z9fedceMYuZzGktX2gmobNYZkrIZj4jRaz1kqWx hurUXhGBrl4WXjtRX1t28AlEgxHBM1Yd2C+HBi2uQT8k+LrGBAYjbZEf3ChJ4VzN43L4 u2OmGGupVP7gSQbq0a8E6IOaIQhqhJajJNf7b150O6o8w+72m3d4obM0F2oQDhthUpsh Mi3g== X-Gm-Message-State: AOAM531Q/eYRE/kUwxRO7MVBbWpJKpe5hdV/BIZkBrsecggMIn/dDC1P B96Oazun2xdz1fGecZm3OIKQcnnmmG9MFA== X-Google-Smtp-Source: ABdhPJzDrEu9wOlrMyduiR1jrb4hiphUKP52ohYlB1BbihMZjp57R5aT9rTzNo26ArqcWr6cGQDdTQ== X-Received: by 2002:a63:1f10:: with SMTP id f16mr44339831pgf.111.1609259920342; Tue, 29 Dec 2020 08:38:40 -0800 (PST) Received: from mike-mac.lan ([107.182.37.0]) by smtp.gmail.com with ESMTPSA id h1sm28129117pgj.59.2020.12.29.08.38.39 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 29 Dec 2020 08:38:39 -0800 (PST) To: Todd Herr Cc: "dmarc@ietf.org" References: <9f6782b1-e85b-1a9c-9151-98feff7e18ea@mtcc.com> From: Michael Thomas Message-ID: <140485eb-020f-4406-3f2f-e2c475ea51e5@mtcc.com> Date: Tue, 29 Dec 2020 08:38:38 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------6768575B4B827AE76B6DB809" Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] auth-res vs. dmarc X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Dec 2020 16:38:44 -0000 This is a multi-part message in MIME format. --------------6768575B4B827AE76B6DB809 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 12/28/20 5:17 AM, Todd Herr wrote: > On Sat, Dec 26, 2020 at 6:48 PM Michael Thomas > wrote: > > > I installed this handy dandy t-bird dkim verifier extension which > also > allows you to just use the upstream auth-res.  After fixing a bug > in it, > I could see that it lists DMARC as a fail when DKIM failed, but SPF > passed. The _dmarc record has p=none, so it seems really odd to call > that a DMARC failure. Shouldn't it just be using the appropriate > p= tag > instead of "fail"? Is this left over from when Auth-res was mainly > for dkim? > > > A DMARC pass verdict requires not only that SPF or DKIM pass, but also > that the SPF or DKIM domain in question align with the DMARC > (RFC5322.From) domain. A message such as the following: > > * Return-Path: > > * DKIM domain: b.org > * From: bar@c.com > > Can get an SPF pass for a.net and have its DKIM > signature validate, but still fail DMARC for c.com > because neither a.net nor b.org align > with c.com . > > Can you share the example auth-res header(s) in question along with > the DMARC policy record(s) for the message(s)? > Mail from this list is being set to DMARC=fail in the authentication results even with _DMARC is set to "p=none". My mail provider -- google -- is the one that is creating that auth-res. I just looked through DMARC and AUTH-RES (rfc 7601) and couldn't find any guidance as to what qualifies as "fail". Did I overlook something? My feeling is that failure should be reserved only in the case where both SPF and DKIM fail and that the p= > none. What I'd *really* like from a UI standpoint is the p= value passed along as well so I can decide to decorate reject differently from quarantine and none. Mike --------------6768575B4B827AE76B6DB809 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit


On 12/28/20 5:17 AM, Todd Herr wrote:
On Sat, Dec 26, 2020 at 6:48 PM Michael Thomas <mike@mtcc.com> wrote:

I installed this handy dandy t-bird dkim verifier extension which also
allows you to just use the upstream auth-res.  After fixing a bug in it,
I could see that it lists DMARC as a fail when DKIM failed, but SPF
passed. The _dmarc record has p=none, so it seems really odd to call
that a DMARC failure. Shouldn't it just be using the appropriate p= tag
instead of "fail"? Is this left over from when Auth-res was mainly for dkim?


A DMARC pass verdict requires not only that SPF or DKIM pass, but also that the SPF or DKIM domain in question align with the DMARC (RFC5322.From) domain. A message such as the following:
Can get an SPF pass for a.net and have its DKIM signature validate, but still fail DMARC for c.com because neither a.net nor b.org align with c.com.

Can you share the example auth-res header(s) in question along with the DMARC policy record(s) for the message(s)?


Mail from this list is being set to DMARC=fail in the authentication results even with _DMARC is set to "p=none". My mail provider -- google -- is the one that is creating that auth-res. I just looked through DMARC and AUTH-RES (rfc 7601) and couldn't find any guidance as to what qualifies as "fail". Did I overlook something?

My feeling is that failure should be reserved only in the case where both SPF and DKIM fail and that the p= > none. What I'd *really* like from a UI standpoint is the p= value passed along as well so I can decide to decorate reject differently from quarantine and none.

Mike

--------------6768575B4B827AE76B6DB809-- From nobody Tue Dec 29 09:18: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 670FC3A148C for ; Tue, 29 Dec 2020 09:18:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=valimail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MKJSAACv1Ndj for ; Tue, 29 Dec 2020 09:18:17 -0800 (PST) Received: from mail-qv1-xf2f.google.com (mail-qv1-xf2f.google.com [IPv6:2607:f8b0:4864:20::f2f]) (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 4D6D73A148B for ; Tue, 29 Dec 2020 09:18:17 -0800 (PST) Received: by mail-qv1-xf2f.google.com with SMTP id l7so6621202qvt.4 for ; Tue, 29 Dec 2020 09:18:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=0cHt5egd57XNr54tEuA6LZovm/cGuOVe4R833qLsu78=; b=gKn24G7TzAeXPnq8kw1rrfRMcCBWaICCkC/PTLTFpY4oXrARmSTswL1AXLOmYaXxNN TLkFZLSVrW8MCEOBC+k+O4RqDFH0kde1GzjbotAm/Z9uRQP3OTlaFsFrME0ryJWtKtv/ vApMqu6z/feJWM/jnzrATsbbFRROFEPLOOALYSGytzSGr5E0/Fkl1n9tZVDzHzlCJz+l KI1//xuCid08pUpGGp4EK71ku465l2AE/KJecD+5XG0p+VfoTSU2U4AGe2mmMHuW7+tE WPRqvdmiFhjKUvZuxBanl4ae+/GZIkd1UwrHRnwniM0+SjJfMacyiV45bRGnaa9gXz0G heIw== 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=0cHt5egd57XNr54tEuA6LZovm/cGuOVe4R833qLsu78=; b=O34Q8i3/rJ1pkRJSHi/6hUOZO2O34Pl90uHGUczejQRDIBBJiohhteP2y5YVBoB60Y dMoJJpNndOxWcBY3nPaJvnwNMM+x9Z+J+vR3OiyUFKwOZnY4j43gG/MqRyHMUoYPtFOe 2On+BiqvWtxrN2Cx17guFoy+wendwfa/MoMI39f288Vu9qTLPvT9vQkYYuB/fYjVVmHP k00VKf0KYZfcNUhXb1ZzoTOup7XIIv3SjayaUeBbzNxrLdG8c5YnyDxITdsB6sf7CTJ4 Q/hVKrxE39yqy4z+qXqxn6/TtZNb0XGyCV2Va7dUQspEQ0h4IO9Xk0ZiTotJ8aT/hQF2 ukdg== X-Gm-Message-State: AOAM530PBfxArQlD8KAJd/IJo327rBLtjtbt2LVsN5t1Sk37x6IKO111 gpzB+Dc49aEGVgygV2mBwVWIQOcDFqWA4Pn1k0nI9phmMpg= X-Google-Smtp-Source: ABdhPJweys7V7NglyQX/WJgv0N1Li4EJQMXgHmdOPKPISptE/y4N98ov+M58xnXMZBed2bTmHZkQY6F6nPonsW2cbuo= X-Received: by 2002:a05:6214:684:: with SMTP id r4mr45747361qvz.54.1609262295843; Tue, 29 Dec 2020 09:18:15 -0800 (PST) MIME-Version: 1.0 References: <9f6782b1-e85b-1a9c-9151-98feff7e18ea@mtcc.com> <140485eb-020f-4406-3f2f-e2c475ea51e5@mtcc.com> In-Reply-To: <140485eb-020f-4406-3f2f-e2c475ea51e5@mtcc.com> From: Todd Herr Date: Tue, 29 Dec 2020 12:18:00 -0500 Message-ID: To: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="0000000000007e969705b79d93c1" Archived-At: Subject: Re: [dmarc-ietf] auth-res vs. dmarc X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Dec 2020 17:18:19 -0000 --0000000000007e969705b79d93c1 Content-Type: text/plain; charset="UTF-8" On Tue, Dec 29, 2020 at 11:38 AM Michael Thomas wrote: > Mail from this list is being set to DMARC=fail in the authentication > results even with _DMARC is set to "p=none". My mail provider -- google -- > is the one that is creating that auth-res. I just looked through DMARC and > AUTH-RES (rfc 7601) and couldn't find any guidance as to what qualifies as > "fail". Did I overlook something? > Your use of the phrase "set to DMARC=fail" indicates to me that you are interpreting the Authentication-Results header in ways that are different from my understanding of it. My understanding of the Authentication-Results header is that it captures the results of any authentication checks (SPF, DKIM, DMARC) that were performed on the message. DMARC validation results are independent of the DMARC policy record, in that any validation result (pass, fail, other) is possible for any policy value, even p=none. The intent of the p= value is for the domain owner to communicate a request for message handling by the entity evaluation the DMARC results; a policy of p=none means "please treat this message the same as you would have if you hadn't performed a DMARC check on it, regardless of the result obtained from the check". My feeling is that failure should be reserved only in the case where both > SPF and DKIM fail and that the p= > none. What I'd *really* like from a UI > standpoint is the p= value passed along as well so I can decide to decorate > reject differently from quarantine and none. > A typical domain owner with a non-trivial email infrastructure and an eventual goal of getting to p=reject will start with p=none, and will consume aggregate and failure reports, and will use the data in those reports to address any shortcomings in their authentication practices. Aggregate reports containing DMARC failure verdicts will be quite useful to the domain owner, to ferret out those cases where Mike in Marketing has contracted with a third party to send mail on behalf of the domain, or where Ellen the Engineer has a server running off the side of her desk, sending reports to $ARBITRARY_MAILBOXES and ensure that such mailstreams are properly authenticated before updating the DMARC policy to p=quarantine or p=reject. It's not uncommon for some domains to be at p=none for months, perhaps twelve or more, depending on their mailing practices and cadences before making the switch. Domain owners won't move to p=reject until they're sure that enforcement of such a policy won't have a negative impact on their mail flow. -- *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. --0000000000007e969705b79d93c1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Dec 29, 2020 at 11:38 AM Michael = Thomas <mike@mtcc.com> wrote:

Mail from this list is being set to DMARC=3Dfail in the authentication results even with _DMARC is set to "p=3Dnone"= ;. My mail provider -- google -- is the one that is creating that auth-res. I just looked through DMARC and AUTH-RES (rfc 7601) and couldn't find any guidance as to what qualifies as "fail&quo= t;. Did I overlook something?

Your use of the ph= rase "set to DMARC=3Dfail" indicates to me that you=C2=A0are inte= rpreting the Authentication-Results header in ways that are different from = my understanding of it.

My understanding of the Au= thentication-Results header is that it captures the results=C2=A0of any aut= hentication checks (SPF, DKIM, DMARC) that were performed on the message. D= MARC validation results=C2=A0are independent of the DMARC policy record, in= that any validation result (pass, fail, other) is possible for any policy = value, even p=3Dnone.=C2=A0

The intent of the p=3D= value is for the domain owner to communicate a request for message handlin= g by the entity evaluation the DMARC results; a policy of p=3Dnone means &q= uot;please treat this message the same as you would have if you hadn't = performed a DMARC check on it, regardless of the result obtained from the c= heck".

My feeling is that failure should be reserved only in the case where both SPF and DKIM fail and that the p=3D > none. What I'= d *really* like from a UI standpoint is the p=3D value passed along as well so I can decide to decorate reject differently from quarantine and none.

=C2=A0A typical domai= n owner with a non-trivial email infrastructure and an eventual goal of get= ting to p=3Dreject will start with p=3Dnone, and will consume aggregate and= failure reports, and will use the data in those reports to address any sho= rtcomings in their authentication practices. Aggregate reports containing D= MARC failure verdicts will be quite useful to the domain owner, to ferret o= ut those cases where Mike in Marketing has contracted with a third party to= send mail on behalf of the domain, or where Ellen the Engineer has a serve= r running off the side of her desk, sending reports to $ARBITRARY_MAILBOXES= and ensure that such mailstreams are properly authenticated before updatin= g the DMARC policy to p=3Dquarantine or p=3Dreject. It's not uncommon f= or some domains to be at p=3Dnone for months, perhaps twelve or more, depen= ding on their mailing practices and cadences before making the switch. Doma= in owners won't move to p=3Dreject until they're sure that enforcem= ent of such a policy won't have a negative impact on their mail flow.

--
=

Todd Herr<= /b> | Sr. Technical Program Manager
=
e: todd.herr@valimai= l.com
p: 703.22= 0.4153

<= span style=3D"font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-= color:transparent;vertical-align:baseline;white-space:pre-wrap">=


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

--0000000000007e969705b79d93c1-- From nobody Tue Dec 29 09:40: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 4C5223A00D3 for ; Tue, 29 Dec 2020 09:40:22 -0800 (PST) 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 n1U1x7AxmrJ7 for ; Tue, 29 Dec 2020 09:40:21 -0800 (PST) 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 45C543A00D2 for ; Tue, 29 Dec 2020 09:40:21 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01RTQRKNS4KW00E8CV@mauve.mrochek.com> for dmarc@ietf.org; Tue, 29 Dec 2020 09:35:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mrochek.com; s=201712; t=1609263318; bh=ewHxwhE1IkhylbN6K9Ju/+CBAakzJSsXNExHQ9KhZnU=; h=From:Cc:Date:Subject:In-reply-to:References:To:From; b=PRr8Q7ZvkBTBM2pDFoj11yUAiARLH0Rdv/x6rtkAkorFjOltlWqOIa5XHklqPQ0zC IqZveNoYHzmwN9COu1NWEjWUI7TDAW5YoOpJwWtMmfqHvTOIOSfrOkH6Fh5KFR27Ly cKgMVOS40Foj24fHUoCMNqGHOaZttR+5IbF+Kqkg= 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 <01RTJOWYX49S004QVR@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for dmarc@ietf.org; Tue, 29 Dec 2020 09:35:15 -0800 (PST) From: ned+dmarc@mrochek.com Cc: Todd Herr , IETF DMARC WG Message-id: <01RTQRKLD8QK004QVR@mauve.mrochek.com> Date: Tue, 29 Dec 2020 09:22:18 -0800 (PST) In-reply-to: "Your message dated Tue, 29 Dec 2020 10:59:30 +0100" <85fed1c6-4792-316c-836d-9a481c5d4964@tana.it> References: <20201218023900.E73B82ACBB2B@ary.qy> <01RTICXKLL3E0085YQ@mauve.mrochek.com> <8813331f-f5e4-faa5-c6d-11212fc25797@taugh.com> <85fed1c6-4792-316c-836d-9a481c5d4964@tana.it> To: Alessandro Vesely Archived-At: Subject: Re: [dmarc-ietf] Ticket #55 - Clarify legal and privacy implications of failure reports X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Dec 2020 17:40:22 -0000 > On Mon 28/Dec/2020 22:20:55 +0100 Todd Herr wrote: > > > > DMARC validation failures can be caused either due to legitimate mail > > (i.e., mail originated by or on behalf of the publisher of the DMARC > > policy, a.k.a., the domain owner) failing authentication checks due to a > > shortcoming in the authentication practices of the domain owner or some > > other hiccup that occurs in transit, OR by illegitimate mail (i.e., mail > > not originated by or on behalf of the domain owner, so mail intended to > > fraudulently impersonate the domain), specifically the kind of mail that > > DMARC is purported to be designed to stop. > That kind of analysis seems to be missing from the draft. After some years of > experience, we should be able to provide some, I'd hope. If not, we'd better > bluntly drop the draft. I think a list of possible failure causes would be nice to have, because a lot of people seem to think that DMARC is a completely reliable mechanism. I'm not entirely convinced this document is the place for it, but OTOH I'm not convinced it isn't. It also strikes me as more of an exercise in enumeration of possibilities than an actual analysis. Let's see. We have: o Illegitimate mail o Message changed in transit, invalidating DKIM signature o Incorrect DKIM signing o Incorrect SPF setup o Unintentional domain misalignment o Improper assertion of DMARC policy We get regularly get problem reports whose root cause turns out to be one of these things. I've probably missed a bunch, and this may not be the best way to compose the list. Ned From nobody Tue Dec 29 09:48: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 1DEDB3A0140 for ; Tue, 29 Dec 2020 09:48:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, 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=mtcc.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 QFwbGBvKaXoT for ; Tue, 29 Dec 2020 09:48:05 -0800 (PST) Received: from mail-pj1-x1032.google.com (mail-pj1-x1032.google.com [IPv6:2607:f8b0:4864:20::1032]) (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 8D4AC3A0127 for ; Tue, 29 Dec 2020 09:48:05 -0800 (PST) Received: by mail-pj1-x1032.google.com with SMTP id b5so1881626pjl.0 for ; Tue, 29 Dec 2020 09:48:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mtcc.com; s=fluffulence; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=eHiP2ddFCXgkPc34+hiSZ81LZ9LoGj/RHkbrLpZKIFc=; b=lIWAqPplCZtRgVEKS0l/tQ7weEQzE+p8uQldbH2w2YpEkkERKtKVau4pPBAmj4V//L ibOQmgSERMFQZ0HEQOBYZGs7PC2psDEg1LVA1RmF14uHANmcQZM6ZJyu4rmCCw6MHhTa PphO3fdHeS2DwuO2JpegK5SQV5myLA4tQq/5MsM9k3pXhLYX4V7eqwA9LaWcCLzCaJ3b zxi0cF4Nzsh3hOVSDE56cMMF6zur4rZG42Nk0gWSfoDI2R5L75zUcxOvwJEWUbXjpNzl 0FDIZxpLZqrcdKnVFt/QUiNs5CwG8czeck7GVGYNiXk3kFhi1xN2zRHtl+7Y6hy1XFwr VOhA== 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=eHiP2ddFCXgkPc34+hiSZ81LZ9LoGj/RHkbrLpZKIFc=; b=S50ZAu2nMz6NI4rTq2mKTM0Ia1+tlOpLuyt7SGyqVnMHDFdefO0ARty5GbpEwQQWd/ nEWnPkmjjrxE5zJg1FhixTfSOzxTl1cwHkZJfQPTotlj5H5UjpfLUSQ2Bp0JhD9l+k2v mY9EheOusqWj/uBCxXl75NcjszNCA/MBFu9k3IGR8CyjadfVEOlaxfJ0lQNHnQiCKzIA U9Tp5QUmqw2kYBAGt+PmY0aytWptPyTxYz09BECP8AzkgliIlmVeIgNIHAyN5mmv75r8 bPfrbZJWVGlycgRIWiJj/ZvkqD2aJF58l05Ol9msfPQTaMZyg/3AyA3NVIjtUFb5VfkT Ka5A== X-Gm-Message-State: AOAM533sLS3LV3r9sYto3VkcTeI5OKuHylpSsHc7NXvTar6nKsoa7dGx lgMg7YfLaxILjRHn3fWJ/AqokwyiPwXT6A== X-Google-Smtp-Source: ABdhPJzRTtXEMs+rwOyaF1mUPWiw5m9JUcRwWIInhMXfQaGhWuxn8kH97gBhq23yU1hjwvgQksuq/g== X-Received: by 2002:a17:90b:512:: with SMTP id r18mr4830436pjz.166.1609264083622; Tue, 29 Dec 2020 09:48:03 -0800 (PST) Received: from mike-mac.lan ([107.182.37.0]) by smtp.gmail.com with ESMTPSA id e4sm40152466pfh.206.2020.12.29.09.48.02 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 29 Dec 2020 09:48:03 -0800 (PST) To: dmarc@ietf.org References: <9f6782b1-e85b-1a9c-9151-98feff7e18ea@mtcc.com> <140485eb-020f-4406-3f2f-e2c475ea51e5@mtcc.com> From: Michael Thomas Message-ID: <5588dbbe-b876-ed80-c80f-792380e3718f@mtcc.com> Date: Tue, 29 Dec 2020 09:48:01 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------39EEE14F3D5CAEE4B1812865" Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] auth-res vs. dmarc X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Dec 2020 17:48:07 -0000 This is a multi-part message in MIME format. --------------39EEE14F3D5CAEE4B1812865 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 12/29/20 9:18 AM, Todd Herr wrote: > > The intent of the p= value is for the domain owner to communicate a > request for message handling by the entity evaluation the DMARC > results; a policy of p=none means "please treat this message the same > as you would have if you hadn't performed a DMARC check on it, > regardless of the result obtained from the check". Right, but that is not what Google at least is doing  in their Auth-res. It's marking it as DMARC=fail. I think the issue is with rfc 7601 because all I see in it are some DMARC codepoints for IANA unless I missed something. But it could also be considered a fault of DMARC if there isn't normative language on what constitutes pass/neutral or missing/fail. Of course this can just be a Google bug, but it looks more likely underspecification to me. Maybe Murray can chime in here. > > My feeling is that failure should be reserved only in the case > where both SPF and DKIM fail and that the p= > none. What I'd > *really* like from a UI standpoint is the p= value passed along as > well so I can decide to decorate reject differently from > quarantine and none. > >  A typical domain owner with a non-trivial email infrastructure and an > eventual goal of getting to p=reject will start with p=none, and will > consume aggregate and failure reports, and will use the data in those > reports to address any shortcomings in their authentication practices. > Aggregate reports containing DMARC failure verdicts will be quite > useful to the domain owner, to ferret out those cases where Mike in > Marketing has contracted with a third party to send mail on behalf of > the domain, or where Ellen the Engineer has a server running off the > side of her desk, sending reports to $ARBITRARY_MAILBOXES and ensure > that such mailstreams are properly authenticated before updating the > DMARC policy to p=quarantine or p=reject. It's not uncommon for some > domains to be at p=none for months, perhaps twelve or more, depending > on their mailing practices and cadences before making the switch. > Domain owners won't move to p=reject until they're sure that > enforcement of such a policy won't have a negative impact on their > mail flow. > In the mean time, it would be nice for MUA's to be able to do their part with annotating mail. DMARC=fail is really unhelpful with p=none. Mike --------------39EEE14F3D5CAEE4B1812865 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit


On 12/29/20 9:18 AM, Todd Herr wrote:

The intent of the p= value is for the domain owner to communicate a request for message handling by the entity evaluation the DMARC results; a policy of p=none means "please treat this message the same as you would have if you hadn't performed a DMARC check on it, regardless of the result obtained from the check".

Right, but that is not what Google at least is doing  in their Auth-res. It's marking it as DMARC=fail. I think the issue is with rfc 7601 because all I see in it are some DMARC codepoints for IANA unless I missed something. But it could also be considered a fault of DMARC if there isn't normative language on what constitutes pass/neutral or missing/fail. Of course this can just be a Google bug, but it looks more likely underspecification to me.

Maybe Murray can chime in here.


My feeling is that failure should be reserved only in the case where both SPF and DKIM fail and that the p= > none. What I'd *really* like from a UI standpoint is the p= value passed along as well so I can decide to decorate reject differently from quarantine and none.

 A typical domain owner with a non-trivial email infrastructure and an eventual goal of getting to p=reject will start with p=none, and will consume aggregate and failure reports, and will use the data in those reports to address any shortcomings in their authentication practices. Aggregate reports containing DMARC failure verdicts will be quite useful to the domain owner, to ferret out those cases where Mike in Marketing has contracted with a third party to send mail on behalf of the domain, or where Ellen the Engineer has a server running off the side of her desk, sending reports to $ARBITRARY_MAILBOXES and ensure that such mailstreams are properly authenticated before updating the DMARC policy to p=quarantine or p=reject. It's not uncommon for some domains to be at p=none for months, perhaps twelve or more, depending on their mailing practices and cadences before making the switch. Domain owners won't move to p=reject until they're sure that enforcement of such a policy won't have a negative impact on their mail flow.

In the mean time, it would be nice for MUA's to be able to do their part with annotating mail. DMARC=fail is really unhelpful with p=none.

Mike

--------------39EEE14F3D5CAEE4B1812865-- From nobody Tue Dec 29 10:02: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 839343A03F1 for ; Tue, 29 Dec 2020 10:02:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=valimail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dRt8roUxZGY6 for ; Tue, 29 Dec 2020 10:02:17 -0800 (PST) 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 D29F33A03EF for ; Tue, 29 Dec 2020 10:02:16 -0800 (PST) Received: by mail-qt1-x832.google.com with SMTP id c14so9459079qtn.0 for ; Tue, 29 Dec 2020 10:02:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=Xqp6mNj15osy8lc5EK3aOkdvzYLjQUfTYHDNqRQ8x9w=; b=F3ny/ynKY4bJxPXqFnsFHdw9r+VTHPIWzgT9qof2rA+yWl7teh73iKnAF0wfxF1nIk SdSOsipun+k/WPq91ONirAKMtUGf1dxUViGhZ7LO05oOHkjOEemKO+y5Ta5zl9XknovP pINziTjhAiVvnzf8oHFDeYBLPWqZUsAykf4YAB6+O37uQ8hN/fwYCdSod2vfcWVBCYEm iL99SsBzpnamvoigLg6EkLpYcdQFTIQCLiGkhRu+AfsKOY4rxJS4+ff7dYCxUQsorAHu gnjjHy3XSBAx9RNFkIKh+Wd7UwBPlKcJ+gzfzFfQiTaY7V3TeoYBzl/lJod8ygphslrU F3KA== 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=Xqp6mNj15osy8lc5EK3aOkdvzYLjQUfTYHDNqRQ8x9w=; b=VhwlXwbusgGXtPL16GbVfcd3iaEozsL/XpriJQlEB8nxzHz96X1Y/anFmDpXN60W1o 5Xwzdvwc22GNQyqIaI3Dq04Pyrz/EingaPJ08vbT8nZsx7wLdxL69jUqqysq77mmMldr CT0ArS3jNWiN5RkEUSXa9W16vxnlqQiu1HRkJ48LwDofAT30FyNkG23mA8/VNmdqSdV9 5SkXbO9juu0LgqPathHLY83XW9gyz9ecCfhPodv38S8gW7N6d2zZUxlt5vZygQaivxAq /i3ZbKqoNPHJgf6/8QqgZ2H1I9Tnw6mq/J816LEXwPVEFvPObUgJNM85Z5UFPrdAxcMU phdg== X-Gm-Message-State: AOAM533oZhNUD/QNy6c5bV0RIGrw/2pZB+wB8iqoZtBdQAnGnQIiZaUe q8eV6QFiJwtnE/eAazrFmdXL/4Pgw73s3ehARzLZD5dwq3L8RQ== X-Google-Smtp-Source: ABdhPJxRuxoUIgyBCq0yjPFrac0c6qgFixEureaF/QFGxOHZYCafwXwGlJEY717sdiVynkfZx0N7aMJIYH8dWeavrTg= X-Received: by 2002:ac8:3401:: with SMTP id u1mr49092121qtb.220.1609264935637; Tue, 29 Dec 2020 10:02:15 -0800 (PST) MIME-Version: 1.0 References: <9f6782b1-e85b-1a9c-9151-98feff7e18ea@mtcc.com> <140485eb-020f-4406-3f2f-e2c475ea51e5@mtcc.com> <5588dbbe-b876-ed80-c80f-792380e3718f@mtcc.com> In-Reply-To: <5588dbbe-b876-ed80-c80f-792380e3718f@mtcc.com> From: Todd Herr Date: Tue, 29 Dec 2020 13:01:59 -0500 Message-ID: To: IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000d6a8c505b79e30ac" Archived-At: Subject: Re: [dmarc-ietf] auth-res vs. dmarc X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Dec 2020 18:02:20 -0000 --000000000000d6a8c505b79e30ac Content-Type: text/plain; charset="UTF-8" On Tue, Dec 29, 2020 at 12:48 PM Michael Thomas wrote: > > On 12/29/20 9:18 AM, Todd Herr wrote: > > > The intent of the p= value is for the domain owner to communicate a > request for message handling by the entity evaluation the DMARC results; a > policy of p=none means "please treat this message the same as you would > have if you hadn't performed a DMARC check on it, regardless of the result > obtained from the check". > > Right, but that is not what Google at least is doing in their Auth-res. > It's marking it as DMARC=fail. > I'm sorry, but I just don't do well with abstract concepts. Could you please favor me with an example Authentication-Results header that's got you vexed, so that I might understand what you're seeing? > I think the issue is with rfc 7601 because all I see in it are some DMARC > codepoints for IANA unless I missed something. But it could also be > considered a fault of DMARC if there isn't normative language on what > constitutes pass/neutral or missing/fail. Of course this can just be a > Google bug, but it looks more likely underspecification to me. > > Maybe Murray can chime in here. > RFC 7489 contains this text in section 4.2: A message satisfies the DMARC checks if at least one of the supported authentication mechanisms: 1. produces a "pass" result, and 2. produces that result based on an identifier that is in alignment, as defined in Section 3 . > My feeling is that failure should be reserved only in the case where both >> SPF and DKIM fail and that the p= > none. What I'd *really* like from a UI >> standpoint is the p= value passed along as well so I can decide to decorate >> reject differently from quarantine and none. >> > A typical domain owner with a non-trivial email infrastructure and an > eventual goal of getting to p=reject will start with p=none, and will > consume aggregate and failure reports, and will use the data in those > reports to address any shortcomings in their authentication practices. > Aggregate reports containing DMARC failure verdicts will be quite useful to > the domain owner, to ferret out those cases where Mike in Marketing has > contracted with a third party to send mail on behalf of the domain, or > where Ellen the Engineer has a server running off the side of her desk, > sending reports to $ARBITRARY_MAILBOXES and ensure that such mailstreams > are properly authenticated before updating the DMARC policy to p=quarantine > or p=reject. It's not uncommon for some domains to be at p=none for months, > perhaps twelve or more, depending on their mailing practices and cadences > before making the switch. Domain owners won't move to p=reject until > they're sure that enforcement of such a policy won't have a negative impact > on their mail flow. > > In the mean time, it would be nice for MUA's to be able to do their part > with annotating mail. DMARC=fail is really unhelpful with p=none. > > > I'm not sure there's any value in annotating the DMARC fail/p=none combination. The domain owner in that case has not committed to a state where it believes that all of its mail is properly authenticated, and so it's possible that some percentage of legitimate mail sent by or on behalf of the domain owner will fail. -- *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. --000000000000d6a8c505b79e30ac Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Dec 29, 2020 at 12:48 PM Michael = Thomas <mike@mtcc.com> wrote:
=20 =20 =20


On 12/29/20 9:18 AM, Todd Herr wrote:
=20

The intent of the p=3D value is for the domain owner to communicate a request for message handling by the entity evaluation the DMARC results; a policy of p=3Dnone means "please treat this message the same as you would have if y= ou hadn't performed a DMARC check on it, regardless of the result obtained from the check".

Right, but that is not what Google at least is doing=C2=A0 in their Auth-res. It's marking it as DMARC=3Dfail.

I'm sorry, but I just don't do well with abstract concepts. C= ould you please favor me with an example Authentication-Results header that= 's got you vexed, so that I might understand what you're seeing?
=C2=A0
=

I think the issue is with rfc 7601 because all I see in it are some DMARC codepoints for IANA unless I missed something. But it could also be considered a fault of DMARC if there isn't normative language on what constitutes pass/neutral or missing/fail. Of course this can just be a Google bug, but it looks more likely underspecification to me.

Maybe Murray can chime in here.


<= /div>
RFC 7489 contains this text in section 4.2:

<= pre class=3D"gmail-newpage" style=3D"font-size:13.3333px;margin-top:0px;mar= gin-bottom:0px;break-before:page;color:rgb(0,0,0)"> A message satisfies t= he DMARC checks if at least one of the supported authentication mechanisms: 1. produces a "pass" result, and 2. produces that result based on an identifier that is in alignment,=C2= =A0as defined in Sectio= n 3.=C2=A0


My feeling is that failure should be reserved only in the case where both SPF and DKIM fail and that the p=3D > none. What I'd *really* like from a UI standpoint is the p=3D value passed along as well so I can decide to decorate reject differently from quarantine and none.

=C2=A0A typical domain owner with a non-trivial email infrastructure and an eventual goal of getting to p=3Dreject will start with p=3Dnone, and will consume aggregate and failure reports, and will use the data in those reports to address any shortcomings in their authentication practices. Aggregate reports containing DMARC failure verdicts will be quite useful to the domain owner, to ferret out those cases where Mike in Marketing has contracted with a third party to send mail on behalf of the domain, or where Ellen the Engineer has a server running off the side of her desk, sending reports to $ARBITRARY_MAILBOXES and ensure that such mailstreams are properly authenticated before updating the DMARC policy to p=3Dquarantine or p=3Dreject. It's not unco= mmon for some domains to be at p=3Dnone for months, perhaps twelve or more, depending on their mailing practices and cadences before making the switch. Domain owners won't move to p=3Dreject until they're sure that enforcement of such a policy won't have a negative impact on their mail flow.

In the mean time, it would be nice for MUA's to be able to do their part with annotating mail. DMARC=3Dfail is really unhelpful with p=3Dnone.


I'm not sure there's any val= ue in annotating the DMARC fail/p=3Dnone combination. The domain owner in t= hat case has not committed to a state where it believes that all of its mai= l is properly authenticated, and so it's possible that some percentage = of legitimate mail sent by or on behalf of the domain owner will fail.

--

Todd Herr= | Sr. Technical Program Manager
p: 703.220.4= 153


This email and all data transmitted with it c= ontains 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, co= pying or distribution of the information included in this transmission is p= rohibited and may be unlawful. Please immediately notify the sender by repl= ying to this email and then delete it from your system.

--000000000000d6a8c505b79e30ac-- From nobody Tue Dec 29 10:07: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 6B8B03A03FA for ; Tue, 29 Dec 2020 10:07:53 -0800 (PST) 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 JFhASYKMlnmp for ; Tue, 29 Dec 2020 10:07:51 -0800 (PST) Received: from mail.wordtothewise.com (mail.wordtothewise.com [104.225.223.158]) by ietfa.amsl.com (Postfix) with ESMTP id 5BE783A03F8 for ; Tue, 29 Dec 2020 10:07:51 -0800 (PST) Received: from [192.168.0.227] (unknown [37.228.231.27]) by mail.wordtothewise.com (Postfix) with ESMTPSA id 418A69F149; Tue, 29 Dec 2020 10:07:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=wordtothewise.com; s=aardvark; t=1609265270; bh=ezMbtrYet42mkpYxiw5+SGroJ596aik4ooFgTpijfN8=; h=From:Subject:Date:In-Reply-To:Cc:To:References:From; b=YnTpRIoZw3csm3XfKpOchebL5sKqOKjyp52zeornhQBu7gYTOXc/AZFTwFHPYs6pX 4TvIGZCSbojY+5q3t9ecRUrxX4yNqD13MOLi8f8PbORUKPtdpvT+ZhqvIDZa8VDEKx 67XA1EJlwOhiGqf9NbtK58fqJoLBK8NFbEXgGxEw= From: Laura Atkins Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_4F50B907-B64E-4831-B675-CE32F5275EB5" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Date: Tue, 29 Dec 2020 18:07:47 +0000 In-Reply-To: <5588dbbe-b876-ed80-c80f-792380e3718f@mtcc.com> Cc: dmarc@ietf.org To: Michael Thomas References: <9f6782b1-e85b-1a9c-9151-98feff7e18ea@mtcc.com> <140485eb-020f-4406-3f2f-e2c475ea51e5@mtcc.com> <5588dbbe-b876-ed80-c80f-792380e3718f@mtcc.com> X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [dmarc-ietf] auth-res vs. dmarc X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Dec 2020 18:07:54 -0000 --Apple-Mail=_4F50B907-B64E-4831-B675-CE32F5275EB5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 29 Dec 2020, at 17:48, Michael Thomas wrote: >=20 >=20 >=20 > On 12/29/20 9:18 AM, Todd Herr wrote: >>=20 >> The intent of the p=3D value is for the domain owner to communicate a = request for message handling by the entity evaluation the DMARC results; = a policy of p=3Dnone means "please treat this message the same as you = would have if you hadn't performed a DMARC check on it, regardless of = the result obtained from the check". > Right, but that is not what Google at least is doing in their = Auth-res. It's marking it as DMARC=3Dfail. I think the issue is with rfc = 7601 because all I see in it are some DMARC codepoints for IANA unless I = missed something. But it could also be considered a fault of DMARC if = there isn't normative language on what constitutes pass/neutral or = missing/fail. Of course this can just be a Google bug, but it looks more = likely underspecification to me. >=20 RFC 7489 specifically says that if the domains don=E2=80=99t align then = the mail fails DMARC.=20 5. Conduct Identifier Alignment checks. With authentication checks and policy discovery performed, the Mail Receiver checks to see if Authenticated Identifiers fall into alignment as described in Section 3 . If = one or more of the Authenticated Identifiers align with the RFC5322 .=46rom = domain, the message is considered to pass the DMARC mechanism check. All other conditions (authentication failures, identifier mismatches) are considered to be DMARC mechanism check failures.=20 > Maybe Murray can chime in here. >=20 >> My feeling is that failure should be reserved only in the case where = both SPF and DKIM fail and that the p=3D > none. What I'd *really* like = from a UI standpoint is the p=3D value passed along as well so I can = decide to decorate reject differently from quarantine and none. >>=20 >> A typical domain owner with a non-trivial email infrastructure and = an eventual goal of getting to p=3Dreject will start with p=3Dnone, and = will consume aggregate and failure reports, and will use the data in = those reports to address any shortcomings in their authentication = practices. Aggregate reports containing DMARC failure verdicts will be = quite useful to the domain owner, to ferret out those cases where Mike = in Marketing has contracted with a third party to send mail on behalf of = the domain, or where Ellen the Engineer has a server running off the = side of her desk, sending reports to $ARBITRARY_MAILBOXES and ensure = that such mailstreams are properly authenticated before updating the = DMARC policy to p=3Dquarantine or p=3Dreject. It's not uncommon for some = domains to be at p=3Dnone for months, perhaps twelve or more, depending = on their mailing practices and cadences before making the switch. Domain = owners won't move to p=3Dreject until they're sure that enforcement of = such a policy won't have a negative impact on their mail flow. >>=20 > In the mean time, it would be nice for MUA's to be able to do their = part with annotating mail. DMARC=3Dfail is really unhelpful with p=3Dnone.= >=20 But, the mail fails DMARC because the domains don=E2=80=99t align.=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=_4F50B907-B64E-4831-B675-CE32F5275EB5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On 29 Dec 2020, at 17:48, Michael Thomas <mike@mtcc.com> = wrote:

=20 =20


On 12/29/20 9:18 AM, Todd Herr = wrote:

The intent of the p=3D value is for the domain = owner to communicate a request for message handling by the entity evaluation the DMARC results; a policy of p=3Dnone means "please treat this message the same as you would have if you hadn't performed a DMARC check on it, regardless of the result obtained from the check".

Right, but that is not what Google at = least is doing  in their Auth-res. It's marking it as DMARC=3Dfail. I think the issue is = with rfc 7601 because all I see in it are some DMARC codepoints for IANA unless I missed something. But it could also be considered a fault of DMARC if there isn't normative language on what constitutes pass/neutral or missing/fail. Of course this can just be a Google bug, but it looks more likely underspecification to me.

RFC 7489 = specifically says that if the domains don=E2=80=99t align then the mail = fails DMARC. 

   5.  Conduct Identifier Alignment checks.  With =
authentication checks
       and policy discovery performed, the Mail Receiver checks to see
       if Authenticated Identifiers fall into alignment as described in
       Section 3.  If one or more of the Authenticated =
Identifiers align
       with the RFC5322.=46rom domain, the message is considered to pass
       the DMARC mechanism check.  All other conditions (authentication
       failures, identifier mismatches) are considered to be DMARC
       mechanism check failures.

Maybe Murray can chime in here.

My feeling is that failure should be reserved only in the case where both SPF and DKIM fail and that the p=3D > none. What I'd *really* like from a UI standpoint is the p=3D value passed along as well so I can decide = to decorate reject differently from quarantine and = none.

 A typical domain owner with a = non-trivial email infrastructure and an eventual goal of getting to p=3Dreject will start with p=3Dnone, and will consume aggregate and failure reports, and will use the data in those reports to address any shortcomings in their authentication practices. Aggregate reports containing DMARC failure verdicts will be quite useful to the domain owner, to ferret out those cases where Mike in Marketing has contracted with a third party to send mail on behalf of the domain, or where Ellen the Engineer has a server running off the side of her desk, sending reports to $ARBITRARY_MAILBOXES and ensure that such mailstreams are properly authenticated before updating the DMARC policy to p=3Dquarantine or p=3Dreject. It's not = uncommon for some domains to be at p=3Dnone for months, perhaps = twelve or more, depending on their mailing practices and cadences before making the switch. Domain owners won't move to p=3Dreject until they're sure that enforcement of such a policy won't have a negative impact on their mail = flow.

In the mean time, it would be nice for = MUA's to be able to do their part with annotating mail. DMARC=3Dfail is really unhelpful with p=3Dnone.

But, the mail fails = DMARC because the domains don=E2=80=99t align. 

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=_4F50B907-B64E-4831-B675-CE32F5275EB5-- From nobody Tue Dec 29 10:26: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 605223A0544 for ; Tue, 29 Dec 2020 10:26:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, 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=mtcc.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 WrjH9vU-jU7n for ; Tue, 29 Dec 2020 10:26:45 -0800 (PST) Received: from mail-pj1-x102c.google.com (mail-pj1-x102c.google.com [IPv6:2607:f8b0:4864:20::102c]) (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 900223A05AA for ; Tue, 29 Dec 2020 10:26:45 -0800 (PST) Received: by mail-pj1-x102c.google.com with SMTP id b5so1937065pjk.2 for ; Tue, 29 Dec 2020 10:26:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mtcc.com; s=fluffulence; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=NhWq4HvucbQK8exdf6r6LLD6nhIX66PwU5jBkd+SXDs=; b=FwwtysJ9q4QgDS3P5tniIGw46/q17jB3vsSQfxGwLgDdh9lQz+ptMRRPclCfn6pd/F FJj1XnsdDgXlqbha236aDAPbRZtqhG7npdyXpIdAki6tSyjHdDnNcEq+bBZP11dD5At+ bfHGo6gddvMA5OpbqttC1i/zaYUIAndmxFeg57KGMeBeLAOLuwxuINTJ1HSxzHzYpThP 6oN/i6e2CSSu+2quvrlgaU+bxwJS61yls5j7Ft+PAq5k9s4/ZwrqB8PVphPrF2YEjAUh QkA+nslQqVztzuUr6LgAMLNYm4g41TlDJ1ciqAblX1Cj7hQfNrSZHNuW64BXfnV0ype5 +JLQ== 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=NhWq4HvucbQK8exdf6r6LLD6nhIX66PwU5jBkd+SXDs=; b=V+6OaTzwhNYezRnYzHAB1VJOrN2OvCaxgafLEs7sahaXD8Jw62Y8UKIVmkCQ9wFghy l7g/yuR8rpGp4i4fSmx3JBQT+rOwzy7xTjvN6nOyXfc/IQsd9KPcOr29eRBcVr6dAqUC 4GFMtIyEi14uvSADaYcXqB5aYYZde7KfXg+FtyWgXeVESSBpYjreQ018Pp8rpqZemO1d MHLO9+y25oaPd3LbVMX8tsT0sDHYu9JRv4q2+DsVtEU/1a39xoU4CuDnk1aGVK1yG2lu xlc0YlUfqzxIh7M9XJkTFFJOqX/QKAcHaD6OvmJPx7yQhLoj5aQO87IjGzHxjarIr0+P AE5A== X-Gm-Message-State: AOAM532ds52bvtFYVIozA3I6PNA+h0pWXjB8phBNKZrYwc6iaWuaiGk4 HT7bxMLF43X7yZJFh4aXQJ15Na2tXRoV1A== X-Google-Smtp-Source: ABdhPJyjOUke6n/X0hrDtB3+qbNaY5T8+Jzt3zxDGMou+IHeUz0ZX5dKXumfT9SNDdVX9ZZ52zEs5g== X-Received: by 2002:a17:90a:1b0d:: with SMTP id q13mr4988467pjq.21.1609266403970; Tue, 29 Dec 2020 10:26:43 -0800 (PST) Received: from mike-mac.lan ([107.182.37.0]) by smtp.gmail.com with ESMTPSA id 14sm37849161pfi.131.2020.12.29.10.26.42 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 29 Dec 2020 10:26:43 -0800 (PST) To: Laura Atkins Cc: dmarc@ietf.org References: <9f6782b1-e85b-1a9c-9151-98feff7e18ea@mtcc.com> <140485eb-020f-4406-3f2f-e2c475ea51e5@mtcc.com> <5588dbbe-b876-ed80-c80f-792380e3718f@mtcc.com> From: Michael Thomas Message-ID: <11f33364-05c3-766d-cb65-5b7e68df6463@mtcc.com> Date: Tue, 29 Dec 2020 10:26:41 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------AEBCB23E971646CA2FAD656F" Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] auth-res vs. dmarc X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Dec 2020 18:26:49 -0000 This is a multi-part message in MIME format. --------------AEBCB23E971646CA2FAD656F Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 12/29/20 10:07 AM, Laura Atkins wrote: > > >> On 29 Dec 2020, at 17:48, Michael Thomas > > wrote: >> >> >> On 12/29/20 9:18 AM, Todd Herr wrote: >>> >>> The intent of the p= value is for the domain owner to communicate a >>> request for message handling by the entity evaluation the DMARC >>> results; a policy of p=none means "please treat this message the >>> same as you would have if you hadn't performed a DMARC check on it, >>> regardless of the result obtained from the check". >> >> Right, but that is not what Google at least is doing  in their >> Auth-res. It's marking it as DMARC=fail. I think the issue is with >> rfc 7601 because all I see in it are some DMARC codepoints for IANA >> unless I missed something. But it could also be considered a fault of >> DMARC if there isn't normative language on what constitutes >> pass/neutral or missing/fail. Of course this can just be a Google >> bug, but it looks more likely underspecification to me. >> > RFC 7489 specifically says that if the domains don’t align then the > mail fails DMARC. > > 5. Conduct Identifier Alignment checks. With authentication checks > and policy discovery performed, the Mail Receiver checks to see > if Authenticated Identifiers fall into alignment as described in > Section 3 . If one or more of the Authenticated Identifiers align > with theRFC5322 .From domain, the message is considered to pass > the DMARC mechanism check. All other conditions (authentication > failures, identifier mismatches) are considered to be DMARC > mechanism check failures. > The From address was the original address, and it has an original signature which broke because of the list. Here's one from Ned, auth-res shows DMARC=fail, but his _DMARC is: "v=DMARC1" which should be equivalent to p=none. here's the actual message: Mike Delivered-To: mike@mtcc.com Received: by 2002:a54:25ca:0:0:0:0:0 with SMTP id x10csp10181329eco; Tue, 29 Dec 2020 09:40:32 -0800 (PST) X-Google-Smtp-Source: ABdhPJyg+U7QcElEhZoI4aKc4WUQJDIWF5y8fdwdJmyjtympNYX9FAdff8Hm/Li9AYTGbddL/trG X-Received: by 2002:a9d:336:: with SMTP id 51mr35190952otv.29.1609263632302; Tue, 29 Dec 2020 09:40:32 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1609263632; cv=none; d=google.com; s=arc-20160816; b=dTJ54tXt0rCUsyrv1GwOeH4tt4b0svswn6u/HQWkAaV71Lq8FvoSMoDgE1O89PMWh/ SeSKMR4NfyZsLOTh6KIWQ4nnQXBiPeyQqdVBHFbR+rnRQTPbxSlR6nPHiAa7rdv1ALmL dblBh3d+RQQGhaca/RMd4zT570hheniVq9CFxjCyhoa5aVFiHKgAK98ouRV5G+cmliAP cKuo4J2logklJ2tRkL/WaJbw5eFXXE1fSYrlO5PCINiAIRgjofhv6OfYdZ4DjA+q+B3I JORJjRfm+QS3HtuLNWl1Qood3uZzHNUUfWFXYAO8V7xMix7ueZa+MfzvYDz4pSUq5LYt XtZQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=sender:errors-to:content-transfer-encoding:cc:list-subscribe :list-help:list-post:list-archive:list-unsubscribe:list-id :precedence:subject:archived-at:to:references:in-reply-to:date :message-id:from:mime-version:dkim-signature:delivered-to :dkim-signature:dkim-signature; bh=K1GgIcpwgrhht0uXSnTdvMnH4VecXw2MUZjQBJOuUr0=; b=nLsXAjfcPF4vqV+DPpFvzAkhJVfT8TiRkgDhEck7mOmobi376n+SINg/aife5vS0jB 1ceDHt4zmM9mJaRv/0r4ScjrYStxd1udPBR04PxwO7upqpBKgq3EP+CS0HS7kT3tF5AW VnsuiEOOvgR1SJCFKOg6vFEoDZ0A3WC0XwuYw7a4uiuK34sCMQyTA8rG/Z59BsNUPoKg 68PWKxGvV7WVCNI5cBeT0Zq4K8zNCYUiwvdd/Drohw7q9mqh2EpWneY+HVD6toGwSVqQ SwAyoWMlJY6VPaPt8BsarBo+KpyL2yGa2bd9REDdf5byYvf7QrPrL0KfwlYmSTPDXGnx Ynrg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@ietf.org header.s=ietf1 header.b=aayvF8Pg; dkim=pass header.i=@ietf.org header.s=ietf1 header.b="PwU4/yuQ"; dkim=neutral (body hash did not verify) header.i=@mrochek.com header.s=201712 header.b=PRr8Q7Zv; spf=pass (google.com: domain of dmarc-bounces@ietf.org designates 4.31.198.44 as permitted sender) smtp.mailfrom=dmarc-bounces@ietf.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=mrochek.com Return-Path: Received: from mail.ietf.org (mail.ietf.org. [4.31.198.44]) by mx.google.com with ESMTPS id k26si2675892oig.140.2020.12.29.09.40.32 for (version=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305 bits=256/256); Tue, 29 Dec 2020 09:40:32 -0800 (PST) Received-SPF: pass (google.com: domain of dmarc-bounces@ietf.org designates 4.31.198.44 as permitted sender) client-ip=4.31.198.44; Authentication-Results: mx.google.com; dkim=pass header.i=@ietf.org header.s=ietf1 header.b=aayvF8Pg; dkim=pass header.i=@ietf.org header.s=ietf1 header.b="PwU4/yuQ"; dkim=neutral (body hash did not verify) header.i=@mrochek.com header.s=201712 header.b=PRr8Q7Zv; spf=pass (google.com: domain of dmarc-bounces@ietf.org designates 4.31.198.44 as permitted sender) smtp.mailfrom=dmarc-bounces@ietf.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=mrochek.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D3C43A0637 for ; Tue, 29 Dec 2020 09:40:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1609263631; bh=EGQWffHXRQ6gspv6YxtmRG6Fn28UIhBFVLnT2fAWP+A=; h=From:Date:In-reply-to:References:To:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Cc; b=aayvF8PgSyzrXOZYbNxAumLnlLbDQalrt4v/c80QwqvBZwDP3pKlwFBsokgbGdqyj NAzqqsrLPPXsYkTNPzmpsQmBkHhz9i+qWILS4DjGJEhDwtrz0X6PKXTLDVHgfUxgRt az2SiD/+IPA7iMqhsjjuerYU9UNIlD/Iq4dNtW3M= X-Mailbox-Line: From dmarc-bounces@ietf.org Tue Dec 29 09:40:26 2020 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 770A03A00D8; Tue, 29 Dec 2020 09:40:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1609263624; bh=EGQWffHXRQ6gspv6YxtmRG6Fn28UIhBFVLnT2fAWP+A=; h=From:Date:In-reply-to:References:To:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Cc; b=PwU4/yuQPAZwBP5tbjxZEG1gunIJDSOkf7BOD5fFeiB9+0Kr9B5jxtcsdj8tncl0E PA0Fes+JZac4PX4NFJhQnXyP81gDZckIysH8SV6r3wUy9zxheqUWa0+OpsOaZTcU14 yPn4VMb1pn4H7YHpQfKDEgn6eKmQUfXq6jwZ9wSE= X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C5223A00D3 for ; Tue, 29 Dec 2020 09:40:22 -0800 (PST) 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 n1U1x7AxmrJ7 for ; Tue, 29 Dec 2020 09:40:21 -0800 (PST) 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 45C543A00D2 for ; Tue, 29 Dec 2020 09:40:21 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01RTQRKNS4KW00E8CV@mauve.mrochek.com> for dmarc@ietf.org; Tue, 29 Dec 2020 09:35:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mrochek.com; s=201712; t=1609263318; bh=ewHxwhE1IkhylbN6K9Ju/+CBAakzJSsXNExHQ9KhZnU=; h=From:Cc:Date:Subject:In-reply-to:References:To:From; b=PRr8Q7ZvkBTBM2pDFoj11yUAiARLH0Rdv/x6rtkAkorFjOltlWqOIa5XHklqPQ0zC IqZveNoYHzmwN9COu1NWEjWUI7TDAW5YoOpJwWtMmfqHvTOIOSfrOkH6Fh5KFR27Ly cKgMVOS40Foj24fHUoCMNqGHOaZttR+5IbF+Kqkg= MIME-version: 1.0 Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01RTJOWYX49S004QVR@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for dmarc@ietf.org; Tue, 29 Dec 2020 09:35:15 -0800 (PST) From: ned+dmarc@mrochek.com Message-id: <01RTQRKLD8QK004QVR@mauve.mrochek.com> Date: Tue, 29 Dec 2020 09:22:18 -0800 (PST) In-reply-to: "Your message dated Tue, 29 Dec 2020 10:59:30 +0100" <85fed1c6-4792-316c-836d-9a481c5d4964@tana.it> References: <20201218023900.E73B82ACBB2B@ary.qy> <01RTICXKLL3E0085YQ@mauve.mrochek.com> <8813331f-f5e4-faa5-c6d-11212fc25797@taugh.com> <85fed1c6-4792-316c-836d-9a481c5d4964@tana.it> To: Alessandro Vesely Archived-At: Subject: Re: [dmarc-ietf] Ticket #55 - Clarify legal and privacy implications of failure reports X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Todd Herr , IETF DMARC WG Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Errors-To: dmarc-bounces@ietf.org Sender: "dmarc" > On Mon 28/Dec/2020 22:20:55 +0100 Todd Herr wrote: > > > > DMARC validation failures can be caused either due to legitimate mail > > (i.e., mail originated by or on behalf of the publisher of the DMARC > > policy, a.k.a., the domain owner) failing authentication checks due to a > > shortcoming in the authentication practices of the domain owner or some > > other hiccup that occurs in transit, OR by illegitimate mail (i.e., mail > > not originated by or on behalf of the domain owner, so mail intended to > > fraudulently impersonate the domain), specifically the kind of mail that > > DMARC is purported to be designed to stop. > That kind of analysis seems to be missing from the draft. After some years of > experience, we should be able to provide some, I'd hope. If not, we'd better > bluntly drop the draft. I think a list of possible failure causes would be nice to have, because a lot of people seem to think that DMARC is a completely reliable mechanism. I'm not entirely convinced this document is the place for it, but OTOH I'm not convinced it isn't. It also strikes me as more of an exercise in enumeration of possibilities than an actual analysis. Let's see. We have: o Illegitimate mail o Message changed in transit, invalidating DKIM signature o Incorrect DKIM signing o Incorrect SPF setup o Unintentional domain misalignment o Improper assertion of DMARC policy We get regularly get problem reports whose root cause turns out to be one of these things. I've probably missed a bunch, and this may not be the best way to compose the list. Ned _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc --------------AEBCB23E971646CA2FAD656F Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit


On 12/29/20 10:07 AM, Laura Atkins wrote:


On 29 Dec 2020, at 17:48, Michael Thomas <mike@mtcc.com> wrote:


On 12/29/20 9:18 AM, Todd Herr wrote:

The intent of the p= value is for the domain owner to communicate a request for message handling by the entity evaluation the DMARC results; a policy of p=none means "please treat this message the same as you would have if you hadn't performed a DMARC check on it, regardless of the result obtained from the check".

Right, but that is not what Google at least is doing  in their Auth-res. It's marking it as DMARC=fail. I think the issue is with rfc 7601 because all I see in it are some DMARC codepoints for IANA unless I missed something. But it could also be considered a fault of DMARC if there isn't normative language on what constitutes pass/neutral or missing/fail. Of course this can just be a Google bug, but it looks more likely underspecification to me.

RFC 7489 specifically says that if the domains don’t align then the mail fails DMARC. 

   5.  Conduct Identifier Alignment checks.  With authentication checks
       and policy discovery performed, the Mail Receiver checks to see
       if Authenticated Identifiers fall into alignment as described in
       Section 3.  If one or more of the Authenticated Identifiers align
       with the RFC5322.From domain, the message is considered to pass
       the DMARC mechanism check.  All other conditions (authentication
       failures, identifier mismatches) are considered to be DMARC
       mechanism check failures.


The From address was the original address, and it has an original signature which broke because of the list. 


Here's one from Ned, auth-res shows DMARC=fail, but his _DMARC is: "v=DMARC1" which should be equivalent to p=none.

here's the actual message:

Mike


Delivered-To: mike@mtcc.com
Received: by 2002:a54:25ca:0:0:0:0:0 with SMTP id x10csp10181329eco;
        Tue, 29 Dec 2020 09:40:32 -0800 (PST)
X-Google-Smtp-Source: ABdhPJyg+U7QcElEhZoI4aKc4WUQJDIWF5y8fdwdJmyjtympNYX9FAdff8Hm/Li9AYTGbddL/trG
X-Received: by 2002:a9d:336:: with SMTP id 51mr35190952otv.29.1609263632302;
        Tue, 29 Dec 2020 09:40:32 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; t=1609263632; cv=none;
        d=google.com; s=arc-20160816;
        b=dTJ54tXt0rCUsyrv1GwOeH4tt4b0svswn6u/HQWkAaV71Lq8FvoSMoDgE1O89PMWh/
         SeSKMR4NfyZsLOTh6KIWQ4nnQXBiPeyQqdVBHFbR+rnRQTPbxSlR6nPHiAa7rdv1ALmL
         dblBh3d+RQQGhaca/RMd4zT570hheniVq9CFxjCyhoa5aVFiHKgAK98ouRV5G+cmliAP
         cKuo4J2logklJ2tRkL/WaJbw5eFXXE1fSYrlO5PCINiAIRgjofhv6OfYdZ4DjA+q+B3I
         JORJjRfm+QS3HtuLNWl1Qood3uZzHNUUfWFXYAO8V7xMix7ueZa+MfzvYDz4pSUq5LYt
         XtZQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816;
        h=sender:errors-to:content-transfer-encoding:cc:list-subscribe
         :list-help:list-post:list-archive:list-unsubscribe:list-id
         :precedence:subject:archived-at:to:references:in-reply-to:date
         :message-id:from:mime-version:dkim-signature:delivered-to
         :dkim-signature:dkim-signature;
        bh=K1GgIcpwgrhht0uXSnTdvMnH4VecXw2MUZjQBJOuUr0=;
        b=nLsXAjfcPF4vqV+DPpFvzAkhJVfT8TiRkgDhEck7mOmobi376n+SINg/aife5vS0jB
         1ceDHt4zmM9mJaRv/0r4ScjrYStxd1udPBR04PxwO7upqpBKgq3EP+CS0HS7kT3tF5AW
         VnsuiEOOvgR1SJCFKOg6vFEoDZ0A3WC0XwuYw7a4uiuK34sCMQyTA8rG/Z59BsNUPoKg
         68PWKxGvV7WVCNI5cBeT0Zq4K8zNCYUiwvdd/Drohw7q9mqh2EpWneY+HVD6toGwSVqQ
         SwAyoWMlJY6VPaPt8BsarBo+KpyL2yGa2bd9REDdf5byYvf7QrPrL0KfwlYmSTPDXGnx
         Ynrg==
ARC-Authentication-Results: i=1; mx.google.com;
       dkim=pass header.i=@ietf.org header.s=ietf1 header.b=aayvF8Pg;
       dkim=pass header.i=@ietf.org header.s=ietf1 header.b="PwU4/yuQ";
       dkim=neutral (body hash did not verify) header.i=@mrochek.com header.s=201712 header.b=PRr8Q7Zv;
       spf=pass (google.com: domain of dmarc-bounces@ietf.org designates 4.31.198.44 as permitted sender) smtp.mailfrom=dmarc-bounces@ietf.org;
       dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=mrochek.com
Return-Path: <dmarc-bounces@ietf.org>
Received: from mail.ietf.org (mail.ietf.org. [4.31.198.44])
        by mx.google.com with ESMTPS id k26si2675892oig.140.2020.12.29.09.40.32
        for <mike@mtcc.com>
        (version=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305 bits=256/256);
        Tue, 29 Dec 2020 09:40:32 -0800 (PST)
Received-SPF: pass (google.com: domain of dmarc-bounces@ietf.org designates 4.31.198.44 as permitted sender) client-ip=4.31.198.44;
Authentication-Results: mx.google.com;
       dkim=pass header.i=@ietf.org header.s=ietf1 header.b=aayvF8Pg;
       dkim=pass header.i=@ietf.org header.s=ietf1 header.b="PwU4/yuQ";
       dkim=neutral (body hash did not verify) header.i=@mrochek.com header.s=201712 header.b=PRr8Q7Zv;
       spf=pass (google.com: domain of dmarc-bounces@ietf.org designates 4.31.198.44 as permitted sender) smtp.mailfrom=dmarc-bounces@ietf.org;
       dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=mrochek.com
Received: from ietfa.amsl.com (localhost [IPv6:::1])
	by ietfa.amsl.com (Postfix) with ESMTP id 6D3C43A0637
	for <mike@mtcc.com>; Tue, 29 Dec 2020 09:40:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1;
	t=1609263631; bh=EGQWffHXRQ6gspv6YxtmRG6Fn28UIhBFVLnT2fAWP+A=;
	h=From:Date:In-reply-to:References:To:Subject:List-Id:
	 List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe:
	 Cc;
	b=aayvF8PgSyzrXOZYbNxAumLnlLbDQalrt4v/c80QwqvBZwDP3pKlwFBsokgbGdqyj
	 NAzqqsrLPPXsYkTNPzmpsQmBkHhz9i+qWILS4DjGJEhDwtrz0X6PKXTLDVHgfUxgRt
	 az2SiD/+IPA7iMqhsjjuerYU9UNIlD/Iq4dNtW3M=
X-Mailbox-Line: From dmarc-bounces@ietf.org  Tue Dec 29 09:40:26 2020
Received: from ietfa.amsl.com (localhost [IPv6:::1])
	by ietfa.amsl.com (Postfix) with ESMTP id 770A03A00D8;
	Tue, 29 Dec 2020 09:40:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1;
	t=1609263624; bh=EGQWffHXRQ6gspv6YxtmRG6Fn28UIhBFVLnT2fAWP+A=;
	h=From:Date:In-reply-to:References:To:Subject:List-Id:
	 List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe:
	 Cc;
	b=PwU4/yuQPAZwBP5tbjxZEG1gunIJDSOkf7BOD5fFeiB9+0Kr9B5jxtcsdj8tncl0E
	 PA0Fes+JZac4PX4NFJhQnXyP81gDZckIysH8SV6r3wUy9zxheqUWa0+OpsOaZTcU14
	 yPn4VMb1pn4H7YHpQfKDEgn6eKmQUfXq6jwZ9wSE=
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1])
 by ietfa.amsl.com (Postfix) with ESMTP id 4C5223A00D3
 for <dmarc@ietfa.amsl.com>; Tue, 29 Dec 2020 09:40:22 -0800 (PST)
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 n1U1x7AxmrJ7 for <dmarc@ietfa.amsl.com>;
 Tue, 29 Dec 2020 09:40:21 -0800 (PST)
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 45C543A00D2
 for <dmarc@ietf.org>; Tue, 29 Dec 2020 09:40:21 -0800 (PST)
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com
 (PMDF V6.1-1 #35243) id <01RTQRKNS4KW00E8CV@mauve.mrochek.com> for
 dmarc@ietf.org; Tue, 29 Dec 2020 09:35:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mrochek.com; s=201712; 
 t=1609263318; bh=ewHxwhE1IkhylbN6K9Ju/+CBAakzJSsXNExHQ9KhZnU=; 
 h=From:Cc:Date:Subject:In-reply-to:References:To:From;
 b=PRr8Q7ZvkBTBM2pDFoj11yUAiARLH0Rdv/x6rtkAkorFjOltlWqOIa5XHklqPQ0zC
 IqZveNoYHzmwN9COu1NWEjWUI7TDAW5YoOpJwWtMmfqHvTOIOSfrOkH6Fh5KFR27Ly
 cKgMVOS40Foj24fHUoCMNqGHOaZttR+5IbF+Kqkg=
MIME-version: 1.0
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243)
 id <01RTJOWYX49S004QVR@mauve.mrochek.com>
 (original mail from NED@mauve.mrochek.com) for dmarc@ietf.org; Tue,
 29 Dec 2020 09:35:15 -0800 (PST)
From: ned+dmarc@mrochek.com
Message-id: <01RTQRKLD8QK004QVR@mauve.mrochek.com>
Date: Tue, 29 Dec 2020 09:22:18 -0800 (PST)
In-reply-to: "Your message dated Tue, 29 Dec 2020 10:59:30 +0100"
 <85fed1c6-4792-316c-836d-9a481c5d4964@tana.it>
References: <20201218023900.E73B82ACBB2B@ary.qy>
 <CAJ4XoYdXWTgADpdL1eJuYGnpSY038vj-FW_x1f2rEp1JL0r2oA@mail.gmail.com>
 <01RTICXKLL3E0085YQ@mauve.mrochek.com>
 <c5f7413e-52c1-6710-16e5-63f59d2c24b9@taugh.com>
 <CAL0qLwYDeV9CmFg9qCCGPse00JV30WRiSC4orC-EitK=hiahgA@mail.gmail.com>
 <a79dd75-4d73-d1dc-d6b1-272de866b950@taugh.com>
 <CAL0qLwZXu3FxH7QGBS7PGbeDwfDTGmC=rbPEQidVV4eDJNHLUA@mail.gmail.com>
 <CAJ4XoYeK2cJb+easc=mqCi4ap1932LmbDdfxM1dFZKrdo2a2mw@mail.gmail.com>
 <acfe3d9e-97eb-50ee-26a2-568fdd8359dd@taugh.com>
 <CADyWQ+GJ62jt=dL9Gzuw_O7USNbS=86BqAzu8Rdv9sCb5OpCdw@mail.gmail.com>
 <d4a00be5-bd61-0c05-3431-8d56b39a3550@tana.it>
 <8813331f-f5e4-faa5-c6d-11212fc25797@taugh.com>
 <CAHej_8kpT2ooFoJdsj1X+AV90HEA29yABJVp+EhrpJNXxWpnOA@mail.gmail.com>
 <CAJ4XoYdFHZEras4JC5K04i+PAukWCTBBnwr0zw_CYwDOAe6Sng@mail.gmail.com>
 <CAHej_8kw6JV-wQKOs1yd_z0RsZe=wuew2+ZSJrmY35j-VCcwFw@mail.gmail.com>
 <dc3140ef-dcb6-05e2-71c3-d449f0e76f1f@tana.it>
 <CAHej_8n=ofqBN_6v2VYJ9vKfefcZO1+jWNPPY9vrcK4Jc_gH_A@mail.gmail.com>
 <85fed1c6-4792-316c-836d-9a481c5d4964@tana.it>
To: Alessandro Vesely <vesely@tana.it>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/IhKyBFyr-uHo92Uem1rBLZ1p730>
Subject: Re: [dmarc-ietf] Ticket #55 - Clarify legal and privacy
 implications of failure reports
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting,
 and Compliance \(DMARC\)" <dmarc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dmarc>,
 <mailto:dmarc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dmarc/>
List-Post: <mailto:dmarc@ietf.org>
List-Help: <mailto:dmarc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dmarc>,
 <mailto:dmarc-request@ietf.org?subject=subscribe>
Cc: Todd Herr <todd.herr@valimail.com>, IETF DMARC WG <dmarc@ietf.org>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Errors-To: dmarc-bounces@ietf.org
Sender: "dmarc" <dmarc-bounces@ietf.org>

> On Mon 28/Dec/2020 22:20:55 +0100 Todd Herr wrote:
> >
> > DMARC validation failures can be caused either due to legitimate mail
> > (i.e., mail originated by or on behalf of the publisher of the DMARC
> > policy, a.k.a., the domain owner) failing authentication checks due to a
> > shortcoming in the authentication practices of the domain owner or some
> > other hiccup that occurs in transit, OR by illegitimate mail (i.e., mail
> > not originated by or on behalf of the domain owner, so mail intended to
> > fraudulently impersonate the domain), specifically the kind of mail that
> > DMARC is purported to be designed to stop.


> That kind of analysis seems to be missing from the draft.  After some years of
> experience,  we should be able to provide some, I'd hope.  If not, we'd better
> bluntly drop the draft.

I think a list of possible failure causes would be nice to have, because
a lot of people seem to think that DMARC is a completely reliable mechanism.

I'm not entirely convinced this document is the place for it, but OTOH
I'm not convinced it isn't.

It also strikes me as more of an exercise in enumeration of possibilities than
an actual analysis.

Let's see. We have:

  o Illegitimate mail
  o Message changed in transit, invalidating DKIM signature
  o Incorrect DKIM signing
  o Incorrect SPF setup
  o Unintentional domain misalignment
  o Improper assertion of DMARC policy


We get regularly get problem reports whose root cause turns out to be one of
these things.

I've probably missed a bunch, and this may not be the best way to compose the
list.

				Ned

_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
--------------AEBCB23E971646CA2FAD656F-- From nobody Tue Dec 29 10:29: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 E69233A05AA for ; Tue, 29 Dec 2020 10:28:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, 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=mtcc.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 9cHPUvJ3kynd for ; Tue, 29 Dec 2020 10:28:57 -0800 (PST) Received: from mail-pg1-x52b.google.com (mail-pg1-x52b.google.com [IPv6:2607:f8b0:4864:20::52b]) (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 D07583A0544 for ; Tue, 29 Dec 2020 10:28:57 -0800 (PST) Received: by mail-pg1-x52b.google.com with SMTP id i7so9665197pgc.8 for ; Tue, 29 Dec 2020 10:28:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mtcc.com; s=fluffulence; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=eSWrZ/Qm93dcpqf+4uQ2yVKB7DZpBIaSepQWtJnkqcw=; b=XW+P5zhvUH2fmbnfwe295iRfXO/vdBqzrJicNUrUAtIqXrTkeFxBGFFY6D/oq0JxMU bjRRaqX1VcrDDcbYeX1wj8kiB19LHfvinRh1uO/IEcWlLR7cJMqGbtrkRgVjq/Pfgo7w ZNLywO3Anm4QIkSOm9szMH2eR6j5MMJXymG3P/OFaVK6CI5i71t6Csyup745DAOowfIp zMUPhmd02zO9QW5N8jJEhYhtHS5gWaq/qzJDbQSb8JHBB2X+QL9WAIYPcy/PtJ3s6Mpi YI6XEZ06OGYctIt49GpP8ELpd5n3YFuLNfIuLJeug0BmQkL+fG2zYR8DHGnwK893xnnq u1AA== 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=eSWrZ/Qm93dcpqf+4uQ2yVKB7DZpBIaSepQWtJnkqcw=; b=rs5ZxGiGFhseqL7i/thVDI4HNCdpx9+hBEutLoF/o7urF66+KkqjWUCTOgJigpLYWS k4EJm/E+Fe4Ph+1fsge71nMJTjOvEwCgKP3Sq5VLqRRCGsEWp2SFWJJoWWcwAH4yEmtV RjtCsDiayH5hxrdTBtwzZqx8skcHWjGUIS/uulccByoIjk9fXNgpui9yX8UHTpI584CW BQ9dokDgkOBOq/VPXWTgAsFNB3VzTYjPxvnQbPqjavGA1LoFNRa/OyGdlE61x6LKkWbk s6nsBQVNJblsLBzKiwMGQGXHefX1zw3t9caenQ2rTtDCAnh6l3zwFmgLmdk56fFcOsky Hbig== X-Gm-Message-State: AOAM53231L0p1PefjrdeKxAHXJXEYbsqHchGl+yFyq3FD2wXX41US1J8 omKc3wyEl/NjdJPIp9mYvCjCbFd2RFt5PA== X-Google-Smtp-Source: ABdhPJz1HqTqYXNVZOoJHWmvls5q8B3D5P4TW1cdf9dGd7fJ3ANFbNrgy2VSzxIfzTXzZbxJjQfAnA== X-Received: by 2002:a62:1896:0:b029:197:491c:be38 with SMTP id 144-20020a6218960000b0290197491cbe38mr46111696pfy.15.1609266536911; Tue, 29 Dec 2020 10:28:56 -0800 (PST) Received: from mike-mac.lan ([107.182.37.0]) by smtp.gmail.com with ESMTPSA id d4sm3856592pjz.28.2020.12.29.10.28.55 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 29 Dec 2020 10:28:56 -0800 (PST) To: dmarc@ietf.org References: <9f6782b1-e85b-1a9c-9151-98feff7e18ea@mtcc.com> <140485eb-020f-4406-3f2f-e2c475ea51e5@mtcc.com> <5588dbbe-b876-ed80-c80f-792380e3718f@mtcc.com> From: Michael Thomas Message-ID: <54dd9978-bcd1-6757-ad27-dcef6db6e5f7@mtcc.com> Date: Tue, 29 Dec 2020 10:28:55 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------84772877F6070462DC559E89" Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] auth-res vs. dmarc X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Dec 2020 18:28:59 -0000 This is a multi-part message in MIME format. --------------84772877F6070462DC559E89 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 12/29/20 10:01 AM, Todd Herr wrote: > On Tue, Dec 29, 2020 at 12:48 PM Michael Thomas > wrote: > > > On 12/29/20 9:18 AM, Todd Herr wrote: >> >> The intent of the p= value is for the domain owner to communicate >> a request for message handling by the entity evaluation the DMARC >> results; a policy of p=none means "please treat this message the >> same as you would have if you hadn't performed a DMARC check on >> it, regardless of the result obtained from the check". > > Right, but that is not what Google at least is doing in their > Auth-res. It's marking it as DMARC=fail. > > I'm sorry, but I just don't do well with abstract concepts. Could you > please favor me with an example Authentication-Results header that's > got you vexed, so that I might understand what you're seeing? I just posted an example. Mike --------------84772877F6070462DC559E89 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit


On 12/29/20 10:01 AM, Todd Herr wrote:
On Tue, Dec 29, 2020 at 12:48 PM Michael Thomas <mike@mtcc.com> wrote:


On 12/29/20 9:18 AM, Todd Herr wrote:

The intent of the p= value is for the domain owner to communicate a request for message handling by the entity evaluation the DMARC results; a policy of p=none means "please treat this message the same as you would have if you hadn't performed a DMARC check on it, regardless of the result obtained from the check".

Right, but that is not what Google at least is doing  in their Auth-res. It's marking it as DMARC=fail.

I'm sorry, but I just don't do well with abstract concepts. Could you please favor me with an example Authentication-Results header that's got you vexed, so that I might understand what you're seeing?

I just posted an example.

Mike


--------------84772877F6070462DC559E89-- From nobody Tue Dec 29 10:59: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 0AF4A3A07F7 for ; Tue, 29 Dec 2020 10:59:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.85 X-Spam-Level: X-Spam-Status: No, score=-1.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iecc.com header.b=ubTOC/1H; dkim=pass (2048-bit key) header.d=taugh.com header.b=Tv/tN4zR Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uyj4paQyGULB for ; Tue, 29 Dec 2020 10:59:11 -0800 (PST) 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 630413A07F4 for ; Tue, 29 Dec 2020 10:59:11 -0800 (PST) Received: (qmail 60923 invoked from network); 29 Dec 2020 18:59:10 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=edf8.5feb7c7e.k2012; bh=Wpf6fdpKdidijre1z/UZq7HVS/QIoParjtug0i1hd0w=; b=ubTOC/1Hl8vSLIY2+gY1CwAeoa00K13ocpuKfVpWCjl+HbRE2WuSKsCnjNxAjX9Lq7pHB84iodF2LP9vCynnDrKe2VAU/wFWpuoeBL1k9+f3x+8f2SIxKmz6pQ+CAbPhkT4e8Tm6KdgFrP1C0ivncJdQXA4kN3u+1L7N7fBd1Lw9gAaN/rkC3Wi0gcVXm+EYoTIApftTKyWdY6gokbm5Jx8Hy1z3SHPzGawsJwcXSXRNk2lr4FusiC1u9yswKh0R+4LONE2ozyZahtfiK8iI8IYPgBF4ssPR7Wa9doOvNi4zLtN45HSnTP8Qx0CNcVq8zLRickFrvTm75Iu0j20oGQ== DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=edf8.5feb7c7e.k2012; bh=Wpf6fdpKdidijre1z/UZq7HVS/QIoParjtug0i1hd0w=; b=Tv/tN4zR/SilH8wRKUFGDKKTGE4ybTd3TaQcd45sJqT+uBh4oMqq45fe/eh6t1HPJjTRn9FoLeSJhK78qQvM+4lUCB2o8Gdd+x3S1yl4AiA+4uAuwOVYm1Bhzq2k6f5Fw/A27XdCo5uenqHou48hKksX7qOMF8v76m3HKcZw4o3oDiQymt6Hz6NyZbhHzdzA+WZcl6qC3JV8MS68rdtC+rlUGBgErzGe2ToHKiyDhI84KxWqSJpFO7qiYCiRAkFz/3HKe61IutkM+F88onhfV63Zbcor6FcjSpbzTJV6IQUpYP6k4k21rtXgteBCQgNiPSEkjIHCD2sjPidWzQHMgg== 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; 29 Dec 2020 18:59:09 -0000 Received: by ary.qy (Postfix, from userid 501) id 856AD34F063E; Tue, 29 Dec 2020 13:59:09 -0500 (EST) Date: 29 Dec 2020 13:59:09 -0500 Message-Id: <20201229185909.856AD34F063E@ary.qy> From: "John Levine" To: dmarc@ietf.org Cc: ned+dmarc@mrochek.com In-Reply-To: <01RTQRKLD8QK004QVR@mauve.mrochek.com> Organization: Taughannock Networks X-Headerized: yes Cleverness: minimal Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] Ticket #55 - Clarify legal and privacy implications of failure reports X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Dec 2020 18:59:13 -0000 In article <01RTQRKLD8QK004QVR@mauve.mrochek.com> you write: >I think a list of possible failure causes would be nice to have, because >a lot of people seem to think that DMARC is a completely reliable mechanism. > >I'm not entirely convinced this document is the place for it, but OTOH >I'm not convinced it isn't. Sounds like a separate WCP document. I agree it could be nice to have something to point to when people insist that it's my fault that their DMARC rules don't match the way my mail system works. >It also strikes me as more of an exercise in enumeration of possibilities than >an actual analysis. > >Let's see. We have: > > o Illegitimate mail > o Message changed in transit, invalidating DKIM signature > o Incorrect DKIM signing > o Incorrect SPF setup > o Unintentional domain misalignment > o Improper assertion of DMARC policy Don't forget o Normal forwarding of SPF validated mail o Authorized third party senders with no access to DKIM keys Could be an interesting document. R's, John From nobody Tue Dec 29 11:03: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 860443A0809 for ; Tue, 29 Dec 2020 11:03:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, 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=mtcc.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 4Ln477tyDmOq for ; Tue, 29 Dec 2020 11:03:36 -0800 (PST) Received: from mail-pg1-x535.google.com (mail-pg1-x535.google.com [IPv6:2607:f8b0:4864:20::535]) (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 7AE913A07F7 for ; Tue, 29 Dec 2020 11:03:36 -0800 (PST) Received: by mail-pg1-x535.google.com with SMTP id 15so9723248pgx.7 for ; Tue, 29 Dec 2020 11:03:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mtcc.com; s=fluffulence; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=8hCe5S+reayl8jFlnm+YMyKg2KvUT8uTZkNv2r1t0k8=; b=mHTrKc1iFMs+lf4VompqSuLWTfQM63ufVAg/8arCUvFFCbf0RCOtGK+RdUEc58RtIQ Srd40bySwODZyurHvf2vWMVXloUueM2NLd3B6TKdqzsSFgdLrtRjB4ARvzG82BJgPFyt ZBbKs2t+DKAXSx2k3sRDZHDZ/9lOB+q367DsEYr+9R1cuP//awtoyslD6Gl9Ax43qdmK Q0McDw5G3KJSXaSJaUqqdt3oP47CJURDvQkdKe/CG+Xrd+GOMN5+wgAr7aoDuy8buEYn zoj08FN4YXpdPkYZSydel++KqYO86wTYetCdytn5SFUih2dy5ttu3YnyVqCob0F3hrf1 Llhg== 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=8hCe5S+reayl8jFlnm+YMyKg2KvUT8uTZkNv2r1t0k8=; b=ORV0k8+bVAoLpIhDIEBEIP4RtIr8UvWvOidSkXANRu3KEB3GpiSYipg0XwSqr+L+c1 Cbo+gkcjm6IWWc5D44JWlKXOSPjWTpBuUt9cswybAOipMEKPPABwbcLF7cpy/XW8Ra+o T6z+4ut7yF9LaZgR/TsFtEKtwu7nQzFTeVC3usm9o4NOZN/+62SabBNiMP+Ied8myKQv O9c3UM22my2E929w/f4FKS3f9tkDyXbX9Yhs17hHIxKOf/UF6RLrLh3y8PQTnCe01usE DmrfDTSOtTVje0155fDZeEpYvBsKWPSd38VPBHjacbSWtZnAbshGakbysK7iAW2fHtsL Oq4A== X-Gm-Message-State: AOAM530jhC+UsrqwruDDIAL41jEomQDqqBrzOrK1pjylnSYAwAGClZy2 twRmOy9KQZJgOT1OZIkbKqZTwjeLY4UewA== X-Google-Smtp-Source: ABdhPJzn0Qg+eIQC9HDZPuJBjog/ovjqXW6SAxWSN5vVkKQ+mUFkFnIlPIj0wWby/boVg9d0aKaZOQ== X-Received: by 2002:a63:e24f:: with SMTP id y15mr48451081pgj.366.1609268615539; Tue, 29 Dec 2020 11:03:35 -0800 (PST) Received: from mike-mac.lan ([107.182.37.0]) by smtp.gmail.com with ESMTPSA id 73sm32721801pga.26.2020.12.29.11.03.34 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 29 Dec 2020 11:03:34 -0800 (PST) To: dmarc@ietf.org References: <20201229185909.856AD34F063E@ary.qy> From: Michael Thomas Message-ID: <5d0793ae-de65-cd1d-32ef-c909202a0eb6@mtcc.com> Date: Tue, 29 Dec 2020 11:03:33 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: <20201229185909.856AD34F063E@ary.qy> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] Ticket #55 - Clarify legal and privacy implications of failure reports X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Dec 2020 19:03:38 -0000 On 12/29/20 10:59 AM, John Levine wrote: > > Don't forget > > o Normal forwarding of SPF validated mail > o Authorized third party senders with no access to DKIM keys > If by "authorized" you mean authorized by the originating domain, I don' t have a lot of sympathy since they can delegate them a selector and update their DNS. Not doing so is just lazy. Mike From nobody Tue Dec 29 11:35: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 67BBF3A08D6 for ; Tue, 29 Dec 2020 11:35:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=valimail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wqxXLQAM8Q7t for ; Tue, 29 Dec 2020 11:35:28 -0800 (PST) Received: from mail-qk1-x72b.google.com (mail-qk1-x72b.google.com [IPv6:2607:f8b0:4864:20::72b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B9FA3A08D5 for ; Tue, 29 Dec 2020 11:35:27 -0800 (PST) Received: by mail-qk1-x72b.google.com with SMTP id 22so12228692qkf.9 for ; Tue, 29 Dec 2020 11:35:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=vjto0nsCKHBXcjKaT+Pe7UhvT4krnIfchvKYEHt5jE8=; b=ZxDi2QSDaXfiG5cASJLC+hD6itwg1btZ/jmIEUTLzliker4cms76bmXhnAKZ2weOy2 rb1rHeFxgeEyl5/KT9/CMpwA7/+7SJZRh5OubpNjQCfYLHbVH1cXl9cGr2lhAmepupxm OnaeKXvm5kIBLqjd0l3BZqzjllbyARQ8HJbV0XkJztDqGwU2bf0aUbJN3akbWzurwt1o r8S031ykOqB9zSeUCI4kVJpVFbqJXU31TFfntMPy3elWWkqDnXHytr+d6H7swSQ/Pl1t h14fUqvpqzcxmFdO82BoZyjHLYBAVawo68hv+izSLmludBmA7Uj7dFNdXfohtfJhcG/q cgSg== 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=vjto0nsCKHBXcjKaT+Pe7UhvT4krnIfchvKYEHt5jE8=; b=IvowfrTAXrJUj/mc5EY28pOfhXMs5RSWbRzngjtZTdJxWlanxUVxKRxZN+6Z3aIlUY FKAuDrlaYsGM0BW/7jnPJzbZYrnUajMfjj8nOx23lXw30VWUhXo43UioMKqwKdImj0Tj 2oUFnjd2zBA3hp0opZkCVtPvs9WY6uQlD9B0FWdmubUt175sRfbcRWjEt+9GTxyGPEYB AcIogypTD9fSG52APFemJwkCCvyL02zhU4i9lYeFhMNUigvNAK2LFxESPYE6HrN+tGdL ROaAuqIRgFEatZ2u3oBqlgQ/uPax2kkKt3VQmKt3WUR55HGjJgRCPk3rCQJfaVpakIYo zpmw== X-Gm-Message-State: AOAM530yLg71g8sVFJrQYy1K7kdv5u+EAwvDpyv7Rk7f1RbrXndoo8De t5ADmG+8yMWFG+ePDBNoyFpiHmMw5los6MZiPPGJTGKsNuOSCQ== X-Google-Smtp-Source: ABdhPJyPNBiClS8cBAF229rNKcePNutJtDkVXUJHqcrTyW7ki5iwPn0ZvUxcmHvCA1SanaGE/EbY0AYbkOAf5TyDIdg= X-Received: by 2002:a37:a656:: with SMTP id p83mr50849301qke.208.1609270524895; Tue, 29 Dec 2020 11:35:24 -0800 (PST) MIME-Version: 1.0 References: <9f6782b1-e85b-1a9c-9151-98feff7e18ea@mtcc.com> <140485eb-020f-4406-3f2f-e2c475ea51e5@mtcc.com> <5588dbbe-b876-ed80-c80f-792380e3718f@mtcc.com> <54dd9978-bcd1-6757-ad27-dcef6db6e5f7@mtcc.com> In-Reply-To: <54dd9978-bcd1-6757-ad27-dcef6db6e5f7@mtcc.com> From: Todd Herr Date: Tue, 29 Dec 2020 14:35:08 -0500 Message-ID: To: IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000fbf7c405b79f7dab" Archived-At: Subject: Re: [dmarc-ietf] auth-res vs. dmarc X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Dec 2020 19:35:30 -0000 --000000000000fbf7c405b79f7dab Content-Type: text/plain; charset="UTF-8" On Tue, Dec 29, 2020 at 1:29 PM Michael Thomas wrote: > > On 12/29/20 10:01 AM, Todd Herr wrote: > > On Tue, Dec 29, 2020 at 12:48 PM Michael Thomas wrote: > >> >> On 12/29/20 9:18 AM, Todd Herr wrote: >> >> >> The intent of the p= value is for the domain owner to communicate a >> request for message handling by the entity evaluation the DMARC results; a >> policy of p=none means "please treat this message the same as you would >> have if you hadn't performed a DMARC check on it, regardless of the result >> obtained from the check". >> >> Right, but that is not what Google at least is doing in their Auth-res. >> It's marking it as DMARC=fail. >> > I'm sorry, but I just don't do well with abstract concepts. Could you > please favor me with an example Authentication-Results header that's got > you vexed, so that I might understand what you're seeing? > > I just posted an example. > > > Again, the result of the validation check is independent of the p= value in the published policy. The p= value is a request by the domain owner for handling based on the validation check results. Let's look at your example: Return-Path: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1609263631; bh=EGQWffHXRQ6gspv6YxtmRG6Fn28UIhBFVLnT2fAWP+A=; h=From:Date:In-reply-to:References:To:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Cc; b=aayvF8PgSyzrXOZYbNxAumLnlLbDQalrt4v/c80QwqvBZwDP3pKlwFBsokgbGdqyj NAzqqsrLPPXsYkTNPzmpsQmBkHhz9i+qWILS4DjGJEhDwtrz0X6PKXTLDVHgfUxgRt az2SiD/+IPA7iMqhsjjuerYU9UNIlD/Iq4dNtW3M= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1609263624; bh=EGQWffHXRQ6gspv6YxtmRG6Fn28UIhBFVLnT2fAWP+A=; h=From:Date:In-reply-to:References:To:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Cc; b=PwU4/yuQPAZwBP5tbjxZEG1gunIJDSOkf7BOD5fFeiB9+0Kr9B5jxtcsdj8tncl0E PA0Fes+JZac4PX4NFJhQnXyP81gDZckIysH8SV6r3wUy9zxheqUWa0+OpsOaZTcU14 yPn4VMb1pn4H7YHpQfKDEgn6eKmQUfXq6jwZ9wSE= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mrochek.com; s=201712; t=1609263318; bh=ewHxwhE1IkhylbN6K9Ju/+CBAakzJSsXNExHQ9KhZnU=; h=From:Cc:Date:Subject:In-reply-to:References:To:From; b=PRr8Q7ZvkBTBM2pDFoj11yUAiARLH0Rdv/x6rtkAkorFjOltlWqOIa5XHklqPQ0zC IqZveNoYHzmwN9COu1NWEjWUI7TDAW5YoOpJwWtMmfqHvTOIOSfrOkH6Fh5KFR27Ly cKgMVOS40Foj24fHUoCMNqGHOaZttR+5IbF+Kqkg= From: ned+dmarc@mrochek.com Authentication-Results: mx.google.com; dkim=pass header.i=@ietf.org header.s=ietf1 header.b=aayvF8Pg; dkim=pass header.i=@ietf.org header.s=ietf1 header.b="PwU4/yuQ"; dkim=neutral (body hash did not verify) header.i=@mrochek.com header.s=201712 header.b=PRr8Q7Zv; spf=pass (google.com: domain of dmarc-bounces@ietf.org designates 4.31.198.44 as permitted sender) smtp.mailfrom=dmarc-bounces@ietf.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=mrochek.com So, we have a message where: - SPF passed, with the Return-Path domain of ietf.org - DKIM passed (twice), with a DKIM signing domain of ietf.org - DKIM did not pass, with a DKIM signing domain of mrocheck.com - The RFC5322.From domain is mrochek.com, which publishes a DMARC policy record - A DMARC authentication check was done, and it failed, because neither SPF nor DKIM passed with a domain that aligned with mrochek.com. None of the validation checks bothered with the p= value in the mrochek.com DMARC policy record, because the p= value is immaterial to the validation check. Whether DMARC passes or fails is based on whether SPF or DKIM passes or fails with an aligned domain, full stop. Once the DMARC validation result is determined, then the mailbox provider or entity performing the DMARC validation check can refer to the p= value in determining how to dispose of the message, but it doesn't have to. It's worth noting perhaps that Google does record message disposition in the auth-res header, though: dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=mrochek.com As I understand it, the p= in that part of the header is the published policy, the sp= is the published policy for any subdomains, and dis= is the disposition for the message. In this case, the disposition was the same as the policy, but it's not always so; here's a bit from a message in my Gmail spam folder: dmarc=fail (p=REJECT sp=REJECT dis=QUARANTINE) In this case, DMARC validation checks failed for the message, and the published policy for the domain in question was p=reject, but the message was routed to my spam folder (dis=QUARANTINE) -- *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. --000000000000fbf7c405b79f7dab Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Dec 29, 2020 at 1:29 PM Michael T= homas <mike@mtcc.com> wrote:
=
=20 =20 =20


On 12/29/20 10:01 AM, Todd Herr wrote:
=20
On Tue, Dec 29, 2020 at 12:48 PM Michael Thomas <mike@mtcc.= com> wrote:


On 12/29/20 9:18 AM, Todd Herr wrote:

The intent of the p=3D value is for the domain owner to communicate a request for message handling by the entity evaluation the DMARC results; a policy of p=3Dnone means "please trea= t this message the same as you would have if you hadn't performed a DMARC check on it, regardless of the result obtained from the check".

Right, but that is not what Google at least is doing=C2=A0 in their Auth-res. It's marking it as DMARC=3Dfail.

I'm sorry, but I just don't do well with abstract concepts. Could you please favor me with an example Authentication-Results header that's got you vexed, so that I might understand what you're seeing?

I just posted an example.


Again, the result of the validation = check is independent of the p=3D value in the published policy. The p=3D va= lue is a request by the domain owner for handling based on the validation c= heck results.

Let's look at your example:

DKIM-Sig=
nature: v=3D1; a=3Drsa-sha256; c=3Drelaxed/simple; d=3Dietf.org; s=3Dietf1;
	t=3D1609263631; bh=3DEGQWffHXRQ6gspv6YxtmRG6Fn28UIhBFVLnT2fAWP+A=3D;
	h=3DFrom:Date:In-reply-to:References:To:Subject:List-Id:
	 List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe:
	 Cc;
	b=3DaayvF8PgSyzrXOZYbNxAumLnlLbDQalrt4v/c80QwqvBZwDP3pKlwFBsokgbGdqyj
	 NAzqqsrLPPXsYkTNPzmpsQmBkHhz9i+qWILS4DjGJEhDwtrz0X6PKXTLDVHgfUxgRt
	 az2SiD/+IPA7iMqhsjjuerYU9UNIlD/Iq4dNtW3M=3D
DKIM-Signature: v=3D1; a=3Drsa-sha256; c=3Drelaxed/s=
imple; d=3Dietf.org; s=
=3Dietf1;
	t=3D1609263624; bh=3DEGQWffHXRQ6gspv6YxtmRG6Fn28UIhBFVLnT2fAWP+A=3D;
	h=3DFrom:Date:In-reply-to:References:To:Subject:List-Id:
	 List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe:
	 Cc;
	b=3DPwU4/yuQPAZwBP5tbjxZEG1gunIJDSOkf7BOD5fFeiB9+0Kr9B5jxtcsdj8tncl0E
	 PA0Fes+JZac4PX4NFJhQnXyP81gDZckIysH8SV6r3wUy9zxheqUWa0+OpsOaZTcU14
	 yPn4VMb1pn4H7YHpQfKDEgn6eKmQUfXq6jwZ9wSE=3D
From: ned+dmarc@mrochek.com
Authentication-Results: mx.google.com;
       dkim=3Dpass header.i=3D@ietf.org header.s=3Dietf1 header.b=3DaayvF8Pg;
       dkim=3Dpass header.i=3D@ietf.org header.s=3Dietf1 header.b=3D"PwU4/yuQ"=
;
       dkim=3Dneutral (body hash did not verify) header.i=3D@mrochek.com header.s=3D2=
01712 header.b=3DPRr8Q7Zv;
       spf=3Dpass (google.=
com: domain of dmarc-bounces@ietf.org designates 4.31.198.44 as permitted sender) =
smtp.mailfrom=3Ddmarc-bounces@ietf.org;
       dmarc=3Dfail (p=3DNONE sp=3DNONE dis=3DNONE) header.from=3Dmrochek.com
= 
So, we=
 have a message where:
None of the validation checks bothered with the p=3D value i=
n the mrochek.com DMARC policy record, b=
ecause the p=3D value is immaterial to the validation check. Whether DMARC =
passes or fails is based on whether SPF or DKIM passes or fails with an ali=
gned domain, full stop.
<=
br>
Once the DMARC valida=
tion result is determined, then the mailbox provider or entity performing t=
he DMARC validation check can refer to the p=3D value in determining how to=
 dispose of the message, but it doesn't have to. It's worth noting =
perhaps that Google does record message disposition in the auth-res header,=
 though:

dmarc=3Dfail (p=3DNONE sp=3DNONE dis=3DNONE) header.from=3Dmrochek.com

As I understand it, the p=3D in that part of the he=
ader is the published policy, the sp=3D is the published policy for any sub=
domains, and dis=3D is the disposition for the message. In this case, the d=
isposition was the same as the policy, but it's not always so; here'=
;s a bit from a message in my Gmail spam folder:

= 
dmarc=3Dfail (p=3DREJECT sp=3DREJECT=
 dis=3DQUARANTINE)
=
In this case, DMARC validation checks failed for the message, and the publi=
shed policy for the domain in question was p=3Dreject, but the message was =
routed to my spam folder (dis=3DQUARANTINE)
--
=

Todd Herr |= Sr. Technical Program Manager
<= span>
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.

--000000000000fbf7c405b79f7dab-- From nobody Tue Dec 29 11:37: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 890B13A08D6 for ; Tue, 29 Dec 2020 11:37:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.399 X-Spam-Level: X-Spam-Status: No, score=-4.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_MED=-2.3, 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 dYUNC5EGl5FB for ; Tue, 29 Dec 2020 11:37:40 -0800 (PST) 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 BDCAA3A08D5 for ; Tue, 29 Dec 2020 11:37:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1609270658; bh=h92aSWeBHqxNcHga6boYgOaTWEm0QccHpFNi8dnxgC0=; l=3911; h=To:References:From:Date:In-Reply-To; b=APTdC52X+flFvxPQi1No76XzR3PxmksEhgYpy804Lc8ZYQZXBucLNNSUyhzVhIZOQ ncVzzrT9TI0lxd1lpOsnenUZXt+FiOrv+IuLxphGnTfHmC+zRvqF8uRdeQyE4ceLpC sZ/6JAZJZei+gX7bheacDGlWlW76hYTu9V8wSAUPGfrefwpETocGjYfk4R8Ej Authentication-Results: tana.it; auth=pass (details omitted) Original-From: Alessandro Vesely 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.000000005FEB8582.00001C6B; Tue, 29 Dec 2020 20:37:38 +0100 To: ned+dmarc@mrochek.com, Todd Herr , IETF DMARC WG References: <20201218023900.E73B82ACBB2B@ary.qy> <8813331f-f5e4-faa5-c6d-11212fc25797@taugh.com> <85fed1c6-4792-316c-836d-9a481c5d4964@tana.it> <01RTQRKLD8QK004QVR@mauve.mrochek.com> From: Alessandro Vesely Message-ID: <66cf8655-e3c1-e01e-b617-7e76790fada8@tana.it> Date: Tue, 29 Dec 2020 20:37:38 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: <01RTQRKLD8QK004QVR@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] Ticket #55 - Clarify legal and privacy implications of failure reports X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Dec 2020 19:37:43 -0000 On Tue 29/Dec/2020 18:22:18 +0100 ned+dmarc wrote: >> On Mon 28/Dec/2020 22:20:55 +0100 Todd Herr wrote: >>> >>> DMARC validation failures can be caused either due to legitimate mail >>> (i.e., mail originated by or on behalf of the publisher of the DMARC >>> policy, a.k.a., the domain owner) failing authentication checks due to a >>> shortcoming in the authentication practices of the domain owner or some >>> other hiccup that occurs in transit, OR by illegitimate mail (i.e., mail >>> not originated by or on behalf of the domain owner, so mail intended to >>> fraudulently impersonate the domain), specifically the kind of mail that >>> DMARC is purported to be designed to stop. > >> That kind of analysis seems to be missing from the draft.  After some years of >> experience,  we should be able to provide some, I'd hope.  If not, we'd better >> bluntly drop the draft. > > I think a list of possible failure causes would be nice to have, because > a lot of people seem to think that DMARC is a completely reliable mechanism. > > I'm not entirely convinced this document is the place for it, but OTOH > I'm not convinced it isn't. A list of failure causes w/o further considerations may well live in an appendix of the main document. If failure causes are specifically categorized for failure reports, this document becomes a good candidate. > It also strikes me as more of an exercise in enumeration of possibilities than > an actual analysis. > > Let's see. We have: > >  o Illegitimate mail >  o Message changed in transit, invalidating DKIM signature o Unintended DKIM breakage o Intentional DKIM breakage (e.g. MLM) o DKIM signatures not evaluated or not reported o Missing DKIM signature >  o Incorrect DKIM signing >  o Incorrect SPF setup o "Mute" forwarding (SPF failure) o VERP disalignment >  o Unintentional domain misalignment >  o Improper assertion of DMARC policy > > > We regularly get problem reports whose root cause turns out to be one of > these things. The point is working out why one cannot understand the failure reason from aggregate reports. In what cases we do need a failure report in order to understand what's wrong? Maybe we need better aggregate reports? I found one problematic report today, reported by Yahoo! (Oath) on behalf of aol: 4.31.198.44 1 none fail fail tana.it ietf.org pass 4.31.198.44 is mail.ietf.org. DKIM and SPF are not aligned, hence the failure. I'm surprised there are no DKIM signatures. Now I'm going to add "DKIM signatures not evaluated or not reported" to the list above, as it turns out that Yahoo! seem to report valid signatures only. Anyway, would I have got a better understanding had I received a ruf as well? One thing a failure reports brings is the Received: (or ARC) chain. If I wandered how come the IETF sends messages with my header_from, a ruf might help. Is that a real case? Forwarding for email address portability (either "mute" or SRS) is probably not even worth being reported, since there's nothing a mail admin can do about that —updating the address could be done by the author, had the server returned a 251/551. Today's other reports are even more straightforward. But then I run such a tiny server that I don't get an interesting assortment of cases. Another question is *if* I were running a large server and *if* that problematic record had a 1 zillion, how many of the corresponding failure reports would I read, assuming I received any? Best Ale -- From nobody Tue Dec 29 12: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 487FC3A0978 for ; Tue, 29 Dec 2020 12:00:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, 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=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mtcc.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 UqmG512-6C3O for ; Tue, 29 Dec 2020 12:00:57 -0800 (PST) Received: from mail-pj1-x1031.google.com (mail-pj1-x1031.google.com [IPv6:2607:f8b0:4864:20::1031]) (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 A3BEE3A0C1F for ; Tue, 29 Dec 2020 12:00:46 -0800 (PST) Received: by mail-pj1-x1031.google.com with SMTP id lj6so1972890pjb.0 for ; Tue, 29 Dec 2020 12:00:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mtcc.com; s=fluffulence; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=oCHVQ+61ou/B/Kd1Zao0JO0u6LPihiOfHQPfj+1MIsA=; b=APDBMCBABruOoRvBIFMfvXqWKm6pctUzVagVCgFtTkkciNYMi2QQeubS4BpAgd2/tT HGk8SP96/DgBPyY2LxfU6Wtb6ERSbdYdDTM/YgbZN/fXLteB8yZ/XMS++7sj3FuzYgLO WH2HEvq4uJ2NnLHkFayyqBmjpa11Hq/8ESFBaXp+/O0df0Pn+FUXo7soY0cB3KLTog2T WpT5rUHO86aVw/1sfmN1XYSMWPkOLF+IzVo778gHje7/jgh5VtY4KdD8ZBIaC5KmzJAs vzpjBMjUQlXGQpqhCTMzdx/DKpTaambke72QQlNjWco/BiwQc/wGA/Kj+jSxRYRarzcA 6vqg== 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=oCHVQ+61ou/B/Kd1Zao0JO0u6LPihiOfHQPfj+1MIsA=; b=Jso6ibi/kNEC6eRqBlmB+5+aZUqCDXtNNtGuKHLF69EQEI97Vq4fiz40ZGQu7LJrHp tcke+8LYAWeW0xCiVqA4Wj5GXTGgcdDxVZyQutnttC3AYGxKUaeG7zzbqpikZgyIB+p8 xgnELAzLAc0j9Qqpo2m7GFp+l1L2B3pVMKBAk4PaQSK802BebhHJNTOOWurnTbV1K1KD A2/2Wlo38WByIjoMLrGdiPX2P8Nva3Pue34mKHnjUEwIfU51Sqyistt/gEdCgNY9ADOl YxImkcVZLt9uVRu/+KUMq9hszVJmVCrugn8Jk+0tj28wVmrl2SbN1nTvYfpxm9MKzeK/ wmdQ== X-Gm-Message-State: AOAM530vkb5ON7gL00aHhfpQ13wWFrAojje105Es7uw2RL9EssegUAnA dZU7R51aT/Hq3o9rLRxn+rXyIGHuS+6b2A== X-Google-Smtp-Source: ABdhPJzQk0ixjjgy0cRZnCYNmIyHkGulcioOZhZvjKFgEx2JzO+DJXMxRugmuQxN81fOeMIVI9mkMA== X-Received: by 2002:a17:902:b406:b029:db:3c3:e4cd with SMTP id x6-20020a170902b406b02900db03c3e4cdmr50142657plr.79.1609272045613; Tue, 29 Dec 2020 12:00:45 -0800 (PST) Received: from mike-mac.lan ([107.182.37.0]) by smtp.gmail.com with ESMTPSA id g11sm3810647pjb.35.2020.12.29.12.00.44 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 29 Dec 2020 12:00:45 -0800 (PST) To: dmarc@ietf.org References: <9f6782b1-e85b-1a9c-9151-98feff7e18ea@mtcc.com> <140485eb-020f-4406-3f2f-e2c475ea51e5@mtcc.com> <5588dbbe-b876-ed80-c80f-792380e3718f@mtcc.com> <54dd9978-bcd1-6757-ad27-dcef6db6e5f7@mtcc.com> From: Michael Thomas Message-ID: Date: Tue, 29 Dec 2020 12:00:43 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------09425AEBD9B1A062DB773D2A" Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] auth-res vs. dmarc X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Dec 2020 20:00:59 -0000 This is a multi-part message in MIME format. --------------09425AEBD9B1A062DB773D2A Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 12/29/20 11:35 AM, Todd Herr wrote: > None of the validation checks bothered with the p= value in the > mrochek.com DMARC policy record, because the p= > value is immaterial to the validation check. Whether DMARC passes or > fails is based on whether SPF or DKIM passes or fails with an aligned > domain, full stop. > Once the DMARC validation result is determined, then the mailbox > provider or entity performing the DMARC validation check can refer to > the p= value in determining how to dispose of the message, but it > doesn't have to. It's worth noting perhaps that Google does record > message disposition in the auth-res header, though: > > dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=mrochek.com > > Unless those values in parens are a MUST requirement, the dmarc=fail is highly misleading. I haven't even seen any specification for the dmarc part of auth res in rfc  7601, which may be part of the problem. I don't see any normative language which would update rfc7601 in dmarc with the syntax and semantics of the dmarc field. At the very least this needs to be straightened out because auth-res, to Ned's earlier point, can have consumers in the form of MUA's. Mike --------------09425AEBD9B1A062DB773D2A Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit


On 12/29/20 11:35 AM, Todd Herr wrote:
None of the validation checks bothered with the p= value in the mrochek.com DMARC policy record, because the p= value is immaterial to the validation check. Whether DMARC passes or fails is based on whether SPF or DKIM passes or fails with an aligned domain, full stop. 


Once the DMARC validation result is determined, then the mailbox provider or entity performing the DMARC validation check can refer to the p= value in determining how to dispose of the message, but it doesn't have to. It's worth noting perhaps that Google does record message disposition in the auth-res header, though:


dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=mrochek.com
Unless those values in parens are a MUST requirement, the dmarc=fail is highly misleading. I haven't even seen any specification for the dmarc part of auth res in rfc  7601, which may be part of the problem. I don't see any normative language which would update rfc7601 in dmarc with the syntax and semantics of the dmarc field.

At the very least this needs to be straightened out because auth-res, to Ned's earlier point, can have consumers in the form of MUA's.

Mike

--------------09425AEBD9B1A062DB773D2A-- From nobody Tue Dec 29 12:06: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 CAA213A091C for ; Tue, 29 Dec 2020 12:06:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.348 X-Spam-Level: X-Spam-Status: No, score=-0.348 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mtcc.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 CRG8NOw_DBoF for ; Tue, 29 Dec 2020 12:06:24 -0800 (PST) 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 E72163A0934 for ; Tue, 29 Dec 2020 12:06:23 -0800 (PST) Received: by mail-pg1-x52d.google.com with SMTP id n10so9808217pgl.10 for ; Tue, 29 Dec 2020 12:06:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mtcc.com; s=fluffulence; h=to:from:subject:message-id:date:user-agent:mime-version :content-transfer-encoding:content-language; bh=+fn8Gpllc432PmXMSQCnjmIQG3btkdL8rrP+UrlQ0Sk=; b=XMG+S6L2Zb4fFJEyLuOPc9Tya/kcLZ0Ng/F1JrlHY5rhiL0fQBzW50DE33WvJz/Diu Ldijc2oCpApwVPOYGQN3orfaE9xSGGd4f605q9f6iZhPdEh8CAyoW/EXnEIoUXaf16vL 8un+Mix9ncdcu+3/odEyeG2ywzKiab2VmCAhKgb4gRbW+T2M5fdgcDFumCyJMI98DZA5 DRGgl/n8kPSieqSZqLLYGpYezxJlwDaEkhbAOGt6DgTZ/hGYIdjXCZ8ktAiPOSau3oXj 9YIzqQYsraxJueQXzsZ9v42i24FCebfGampy/H3cWKu3GNM+J4nWTZZM50uX6jJ9NZe2 ljuw== 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-transfer-encoding:content-language; bh=+fn8Gpllc432PmXMSQCnjmIQG3btkdL8rrP+UrlQ0Sk=; b=EIQrGOmXvByhXf6BZm8aGFFTLztWedMHRk7YBmuDP1mcbQi98H2zFSYRNtOZqWsr41 BVgPmGU0LlFNE0G0bk+oVmfnKomhRH27QtlEI4FvD6g45Z1+9qfgho/XuJ9e0WeK9+pX cGwciF5GUdh/lQFVt9ZFXIwdXRwVAwZFG9taZiAJ4qtbER3BNz3RgCFwSm8LELQa1GXy C8sRHJvqPFzw4k4TM7nt0Q/WuOkAMxwbVaHJWmvCqYuCnwJRgb2XbCuUdRKZFfnKIHLj AIYnyaJjVS1XTNVJZr3oJJS0YkuGoV3Qtj1VCbdExoOg1l14El0RoCoyso/PFtaE8F7z H5/Q== X-Gm-Message-State: AOAM5304h43lehGRpsIV6TyEUw2TWgHhkOK+u3ET/r/CC+xP/zFce+eh Gv4N2xpjxnVHWuyuV3bu22FD24+F+XjmTA== X-Google-Smtp-Source: ABdhPJztY94eBZ5tQ3RSSMavGR2zlmGOiuKFm36xE5JNdk8bCAGs8HcPZnlecfR635qKlT22zgLn0w== X-Received: by 2002:a65:6645:: with SMTP id z5mr3280829pgv.23.1609272383092; Tue, 29 Dec 2020 12:06:23 -0800 (PST) Received: from mike-mac.lan ([107.182.37.0]) by smtp.gmail.com with ESMTPSA id w21sm40247922pfq.67.2020.12.29.12.06.22 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 29 Dec 2020 12:06:22 -0800 (PST) To: "dmarc@ietf.org" From: Michael Thomas Message-ID: Date: Tue, 29 Dec 2020 12:06:21 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: [dmarc-ietf] pro tip: get a plugin for your MUA for DKIM/DMARC X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Dec 2020 20:06:25 -0000 I started using the dkim-verifier for thunderbird the other day and it's been pretty eye opening. I've been using where it just uses the auth-res rather than verifying the actual signature. I've found a few bugs, but overall it's been very enlightening as I've been seeing some pretty interesting things. My thread with DMARC=fail is a result of one thing I saw which from a UI standpoint was highly misleading. We can probably suss out other issues as well. Mike From nobody Tue Dec 29 12: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 316643A093D for ; Tue, 29 Dec 2020 12:10:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.849 X-Spam-Level: X-Spam-Status: No, score=-1.849 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iecc.com header.b=BRoUoF5Y; dkim=pass (2048-bit key) header.d=taugh.com header.b=Go6iT7lP Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D-OFu995f1Gq for ; Tue, 29 Dec 2020 12:10:56 -0800 (PST) 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 A91D23A0934 for ; Tue, 29 Dec 2020 12:10:56 -0800 (PST) Received: (qmail 81872 invoked from network); 29 Dec 2020 20:10: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:cleverness; s=13fce.5feb8d4e.k2012; bh=C/m5JAcvq4gjqtTwg8F20N4UNe9mXgUqpzH9I8PE/ig=; b=BRoUoF5Ybh/omepwyBgzKn9c5oHaCiRvKnQudUUxG6Lus+6jb5mQXF31SogZC/J8hyh+3xLps7B7uzILOUhDGEV2z1hN2jHWvXqxfnlRM/nGmSl1s/TmZI0M3qebp5ZxPmLLsfiCl2Es0hN/vtKCLXw6N7zVyxHQ42rcxKgD8x9XOopdybjKome32HU5Pv/CFNuF05UJbJmeLX6zQk2nWef0PMunnsGNpIjhdqUS6BZnbvTEnHsgpOXnjwH8nwH+eBNu2EdpVgc65M+0g/f5O60r/rLBhEJNj0WDlvMoK6Rhp/vUmJjj2hcwmK1A24xbaFHIK6TpVGhaoORy/QFCGg== DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=13fce.5feb8d4e.k2012; bh=C/m5JAcvq4gjqtTwg8F20N4UNe9mXgUqpzH9I8PE/ig=; b=Go6iT7lPEbk5lhrrjSAX2ssi4mtjM/QijgE6ZgxyF+/2uzbzgIezCI9kR/wrRgZkwFEdkDXy7/6t7Xw686wYmMlSBHMr+ugbKi01YFM4VouIWZ2d97SbYn/DUYaFyUsELOc0ObskDpSxldk2GjA3S1sfdqQFrbT9TEBYGod+orX17LXnIzFL43QaxTinYtsqg3Uuo1i4ekWQgd0pBN/QCLM/0fgBtzLbMN+gMflrAQzDZcq/owOMdD7Msf2zO7rpB2dJ7QqydQmB39mSW2NtaYQcqxFXfgYPP1mgaFy1SdTySsd2rZy+xoh0vmVAe0OKiwY/ZnJlU+KV4GxFBds3lg== 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; 29 Dec 2020 20:10:53 -0000 Received: by ary.qy (Postfix, from userid 501) id 5A7EC34FD94A; Tue, 29 Dec 2020 15:10:52 -0500 (EST) Date: 29 Dec 2020 15:10:52 -0500 Message-Id: <20201229201053.5A7EC34FD94A@ary.qy> From: "John Levine" To: dmarc@ietf.org Cc: mike@mtcc.com In-Reply-To: <5d0793ae-de65-cd1d-32ef-c909202a0eb6@mtcc.com> Organization: Taughannock Networks X-Headerized: yes Cleverness: minimal Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] Ticket #55 - Clarify legal and privacy implications of failure reports X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Dec 2020 20:10:58 -0000 In article <5d0793ae-de65-cd1d-32ef-c909202a0eb6@mtcc.com> you write: > >On 12/29/20 10:59 AM, John Levine wrote: >> >> Don't forget >> >> o Normal forwarding of SPF validated mail >> o Authorized third party senders with no access to DKIM keys >> >If by "authorized" you mean authorized by the originating domain, I don' >t have a lot of sympathy since they can delegate them a selector and >update their DNS. Not doing so is just lazy. A lot of tiny non-profits like Girl Scout troops use email addresses at webmail providers and send their announcements through ESPs like Constant Contact and Mailchimp. This is yet another situation where DMARC can't describe an entirely normal mail setup. Constant Contact apparently got Yahoo to give them a signing key, at least temporarily, but that doesn't scale. R's, John From nobody Tue Dec 29 12:15: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 C76133A095E for ; Tue, 29 Dec 2020 12:15:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, 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=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mtcc.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 yO7oid9I4J-8 for ; Tue, 29 Dec 2020 12:15:49 -0800 (PST) Received: from mail-pg1-x52e.google.com (mail-pg1-x52e.google.com [IPv6:2607:f8b0:4864:20::52e]) (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 CAE973A0964 for ; Tue, 29 Dec 2020 12:15:49 -0800 (PST) Received: by mail-pg1-x52e.google.com with SMTP id w5so9846075pgj.3 for ; Tue, 29 Dec 2020 12:15:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mtcc.com; s=fluffulence; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=Bc8J/FArbLgjQM1GiB0zKpDLAGxwHoYT2aXeDkHRLn0=; b=EjSjRFnT5qaQwZyefykYgA8EQBbLOsLrIsJHKp398lzBA6/lqUbsqu4ghk4uIvr/+d i7IDSb3HDldUKHgcjkGLMUdKA9z8pW+XQrlX4RxCqnceIRDu/woaSQOSXPcV5TzueOYP w4l81x3o/1UM7CIT9iYAfTz2o+IBJI3YhXCjSEE7ec7YNCsHPKB27dEeJ0w/VJDvP4y4 VmydIn2w8tdrIuJrHz5rq6pifTDYaJ0E0ECi2g6x7dUq+fl11qJqX+E3diE70uunJ6uM Q4BCQKlozJxQ0/c88gHsZV1XVopGo84mIsZM0vFX8ZNVr+wyGKqN/7kVulLns4ha126T FJOA== 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=Bc8J/FArbLgjQM1GiB0zKpDLAGxwHoYT2aXeDkHRLn0=; b=UdF7G/JnDQxXdR60b9botcIeT/W0zF8iLipUhs/H95K2mavg0jQQR6+FNDB6mT81Xd RFr39ZRNP0KUI/9LoNbz3MoCpWQnt+T+V0DJGQOrhYWnL9Zm8JlWBX9dJ98rF3Qg2n7H QxR4iXazS4WWMEOTgD6ZeH8tViSOEtKLSmqzMub0PbzeJGonJA6uEYapahiZeRPeVLI+ xljA9tXlTk56ea7JCS1yc/O6Hc2trnLBR6moqSWxrnpAy6gqjU6GlKTasC587K9fkduN 8iH2UcZCw1jjphomWLZgR9bjxypsXe8i6qBxN2a01DYB3tyS30l18dL57dX3Y5Kp5zF1 LX6A== X-Gm-Message-State: AOAM530v9zBckLZGdCc7QV/NOYh/aIZd+SjyT1PI0aQGAHfk64Giw3cF f7nVCquqya7JjdRa8QPPHWEiUEM0BP89ww== X-Google-Smtp-Source: ABdhPJxGWcEWJeQPzFua3ZzK2jBFypuna3Y18vJtD9ri8ZiCL34i6cJtfdbRPJjbg+v1Djole+ZQuA== X-Received: by 2002:aa7:8486:0:b029:19e:307f:2941 with SMTP id u6-20020aa784860000b029019e307f2941mr26028611pfn.26.1609272948726; Tue, 29 Dec 2020 12:15:48 -0800 (PST) Received: from mike-mac.lan ([107.182.37.0]) by smtp.gmail.com with ESMTPSA id q26sm41323980pfl.219.2020.12.29.12.15.47 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 29 Dec 2020 12:15:48 -0800 (PST) To: John Levine , dmarc@ietf.org References: <20201229201053.5A7EC34FD94A@ary.qy> From: Michael Thomas Message-ID: <14d833ce-0ae0-f818-fd4f-95769266a8e0@mtcc.com> Date: Tue, 29 Dec 2020 12:15:46 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: <20201229201053.5A7EC34FD94A@ary.qy> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] Ticket #55 - Clarify legal and privacy implications of failure reports X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Dec 2020 20:15:51 -0000 On 12/29/20 12:10 PM, John Levine wrote: > In article <5d0793ae-de65-cd1d-32ef-c909202a0eb6@mtcc.com> you write: >> On 12/29/20 10:59 AM, John Levine wrote: >>> Don't forget >>> >>> o Normal forwarding of SPF validated mail >>> o Authorized third party senders with no access to DKIM keys >>> >> If by "authorized" you mean authorized by the originating domain, I don' >> t have a lot of sympathy since they can delegate them a selector and >> update their DNS. Not doing so is just lazy. > A lot of tiny non-profits like Girl Scout troops use email addresses > at webmail providers and send their announcements through ESPs like > Constant Contact and Mailchimp. This is yet another situation where > DMARC can't describe an entirely normal mail setup. > > Constant Contact apparently got Yahoo to give them a signing key, > at least temporarily, but that doesn't scale. What gmail does for gsuite is generates (or not, who knows) a key and gives you the selector to add to your dns. I don't see why that doesn't scale for all situations. Mike From nobody Tue Dec 29 12:47: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 B1B733A09D6 for ; Tue, 29 Dec 2020 12:47:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sHFBJUO35uQC for ; Tue, 29 Dec 2020 12:47:33 -0800 (PST) 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 130CA3A09D7 for ; Tue, 29 Dec 2020 12:47:33 -0800 (PST) Received: by mail-vk1-xa31.google.com with SMTP id u67so3230770vkb.5 for ; Tue, 29 Dec 2020 12:47:33 -0800 (PST) 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=mDidAbTHSvMGrM493pV0d6M7WU4l6FCxoTo1j/YWLcc=; b=joAiyoSUlBsIocf+AB/QkWT3Tu5QwNlRBDV7MvQc2cIGLhGmXdqe7Ugq+plusnJp0t /mKLjrXAIhpGIBJtGvuKT6hNtcCc+nSYhnFGpFZPUUnzQtkkWOW69IAxb+RKjUNQeeN1 8LS+Y/HesEiiBwpBaIQilAokjpmPEIbllTF+oJZClWGn1oqJzicTdQ0F5DAounjkjNL4 94OCmJx736789VlaSknVLQ4102i5S2ZHoUdB8LZ9nLArxRFnqWyv0oJEllTqybM7ZCT+ lg2YZdE2qcOQpTAEL2pOB6/kE0jx4m5hp7tzZkXfXrcmvasqaFj9IB4tlhUFtGYcUNMO BSbg== 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=mDidAbTHSvMGrM493pV0d6M7WU4l6FCxoTo1j/YWLcc=; b=TfPqrsNzMng/4VX4bIa2GrDNjZQi1MS4prnRVDzDVoYViDeGwwi5gHMGxUxMNOt+Iv pkD0nG5Dl/5HM0g2w2foszGVXdJuMMagFYDIC7XnZnS31BhJb/PyjsRJ8H7RJBxeMeM/ 1O1QFwDzWqaSJEvNe2Nv0m1kJs3JPpLMjUhu0T3Pzw4X4bWc23F5LbpMJdHoZILdTkTz jGJzF3Jm9yFShkIUvPfYewoxm58qQ/OiWcbf+QBQitE1KbLfj4Nbpg7YWHpthPhIBbl2 uIvPqtDUsRnwc3dmE4OSEdZRb5t4V1+zrnBYJOaYWId7ZDkrAlcxzBtHqVG/spPL5cis m+dw== X-Gm-Message-State: AOAM53127BOn8vQHCM1Dq1SkQbbwcf5J/w8puE8YEd23Phegs+SJuTBh Eoqpfqvu2DT5BTzUQhNGKRsQoFHN/Tgvgme76UjlW0Ae X-Google-Smtp-Source: ABdhPJx5FKWhICmAMipX8e1oPqulf/1VabsYgUBaSJaWLqGFQbkDtnoR2xUvkgBhxwZq06H/jMOIn+wNo2kpvu61yjI= X-Received: by 2002:a1f:20d1:: with SMTP id g200mr32211807vkg.25.1609274851950; Tue, 29 Dec 2020 12:47:31 -0800 (PST) MIME-Version: 1.0 References: <5d0793ae-de65-cd1d-32ef-c909202a0eb6@mtcc.com> <20201229201053.5A7EC34FD94A@ary.qy> In-Reply-To: <20201229201053.5A7EC34FD94A@ary.qy> From: Douglas Foster Date: Tue, 29 Dec 2020 15:47:18 -0500 Message-ID: To: IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000e58cd105b7a07f39" Archived-At: Subject: Re: [dmarc-ietf] Ticket #55 - Clarify legal and privacy implications of failure reports X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Dec 2020 20:47:35 -0000 --000000000000e58cd105b7a07f39 Content-Type: text/plain; charset="UTF-8" My review of messages from Constant Contact and other major E.S.P.s is that they do obtain and use a DKIM selector when the domain has dmarc enforcement. Earlier in this discussion I was assured that conditionally applying the right signature was not a significant burden for them. Scaling does not seem to be a problem yet. On Tue, Dec 29, 2020, 3:11 PM John Levine wrote: > In article <5d0793ae-de65-cd1d-32ef-c909202a0eb6@mtcc.com> you write: > > > >On 12/29/20 10:59 AM, John Levine wrote: > >> > >> Don't forget > >> > >> o Normal forwarding of SPF validated mail > >> o Authorized third party senders with no access to DKIM keys > >> > >If by "authorized" you mean authorized by the originating domain, I don' > >t have a lot of sympathy since they can delegate them a selector and > >update their DNS. Not doing so is just lazy. > > A lot of tiny non-profits like Girl Scout troops use email addresses > at webmail providers and send their announcements through ESPs like > Constant Contact and Mailchimp. This is yet another situation where > DMARC can't describe an entirely normal mail setup. > > Constant Contact apparently got Yahoo to give them a signing key, > at least temporarily, but that doesn't scale. > > R's, > John > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > --000000000000e58cd105b7a07f39 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
My review of messages from Constant Contact and other maj= or E.S.P.s is that they do obtain and use a DKIM selector when the domain h= as dmarc enforcement.=C2=A0 =C2=A0

Earlier in this discussion I was assured that conditionally applying t= he right signature was not a significant burden for them.

Scaling does not seem to be a problem yet= .

On Tue, Dec 29, 2020, 3:11 PM John Levine <johnl@taugh.com> wrote:
In article <5d0793ae-de65-cd1d-32ef-= c909202a0eb6@mtcc.com> you write:
>
>On 12/29/20 10:59 AM, John Levine wrote:
>>
>> Don't forget
>>
>>=C2=A0 =C2=A0o Normal forwarding of SPF validated mail
>>=C2=A0 =C2=A0o Authorized third party senders with no access to DKI= M keys
>>
>If by "authorized" you mean authorized by the originating dom= ain, I don'
>t have a lot of sympathy since they can delegate them a selector and >update their DNS. Not doing so is just lazy.

A lot of tiny non-profits like Girl Scout troops use email addresses
at webmail providers and send their announcements through ESPs like
Constant Contact and Mailchimp.=C2=A0 This is yet another situation where DMARC can't describe an entirely normal mail setup.

Constant Contact apparently got Yahoo to give them a signing key,
at least temporarily, but that doesn't scale.

R's,
John

_______________________________________________
dmarc mailing list
dmar= c@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
--000000000000e58cd105b7a07f39-- From nobody Tue Dec 29 12:47: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 751983A09E8 for ; Tue, 29 Dec 2020 12:47:57 -0800 (PST) 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 Oo5AKbH77LbQ for ; Tue, 29 Dec 2020 12:47:55 -0800 (PST) Received: from mail-qv1-xf33.google.com (mail-qv1-xf33.google.com [IPv6:2607:f8b0:4864:20::f33]) (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 C9C273A09E7 for ; Tue, 29 Dec 2020 12:47:53 -0800 (PST) Received: by mail-qv1-xf33.google.com with SMTP id a4so6857159qvd.12 for ; Tue, 29 Dec 2020 12:47:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=526RaXvNLe02I36zvsjLX3sFRiHyFAlR/qWdkyzIQMw=; b=Ad3r0LIZ0w0/b6RG7WfIUY+no8QPAEGY/h/OrzggQZjsGXjk45LoaF8qOwazNO2QeN w7W3w1Oa7mZ6X0Ew2kMCSWO6pAycxN1z08E/YYBBiMSUOBlFNDB3AVoQAS6uJ7L1ailH 48lPYRtg8gFWCfXbXK4Wu+QyM4TDJUk1088wngQ0VXEbbKtlkl773DMR7qG7WT+tSeWY SR1xJIiEfLJJQmfjPqtTSKqb7/JtRRX/Ci8c8e3nF80vhXDNhLsi6DRxBw29bIHsi2vf YFGwwHXBGZwE1lrDSqQ6QIEdkgsP6+ccnXQaC33weHbyPnAX8B83MD4/DyYfUmT2cO1F ByNA== 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=526RaXvNLe02I36zvsjLX3sFRiHyFAlR/qWdkyzIQMw=; b=Z62K6DpaCBZ+qpIsBL0OXHlp1nySHRhWUa+IooXgWUlKnKxYN+uX+t+skBrNUwKxDb 8A6EEyG9EW4wWHVj3Gl3wIdy0yIkJ4ypvanQckVDr7trPEbcyEIK541n4LDy5FVpk1zN 9gPFIejxA8mPVkRv4CxU5uBWQEychyrhPgrMr7XOKfnjhvqNZP1c9Ko/7a5ef4W0nfxh k+AaSo+px2jeki2HKBHkbTkPN9BosyJ57cX/t49T1hzy1kpl8mj/obLOmgwmvQJ2CBOh vabDfaNp5yv/4jFUDgmkj6ZMjx295Cm6kHOhCQFtzQs6rEN2Xge/5VTXBvhKp8n5qzi4 Uk6w== X-Gm-Message-State: AOAM530flPpGguHJQHa+ct1d04wDy4SjcsQgS6GA9yDZ2C6KMhIcK8+E cKS7duLJxbyEIb+K8Zb07Q8FfHyQ2nDyEVdiYbjXrYU7lNjRUQ== X-Google-Smtp-Source: ABdhPJwXDweOCm3y/XYMqMkXaJRNlTOXt2KPQy+gsdKOmZuzIT+/lKzD06SBUN69ar82XABWpN9pdLGudk7fwhzOhdI= X-Received: by 2002:a05:6214:684:: with SMTP id r4mr46576255qvz.54.1609274872665; Tue, 29 Dec 2020 12:47:52 -0800 (PST) MIME-Version: 1.0 References: <9f6782b1-e85b-1a9c-9151-98feff7e18ea@mtcc.com> <140485eb-020f-4406-3f2f-e2c475ea51e5@mtcc.com> <5588dbbe-b876-ed80-c80f-792380e3718f@mtcc.com> <54dd9978-bcd1-6757-ad27-dcef6db6e5f7@mtcc.com> In-Reply-To: From: Todd Herr Date: Tue, 29 Dec 2020 15:47:36 -0500 Message-ID: To: IETF DMARC WG Content-Type: multipart/alternative; boundary="00000000000021af5305b7a08163" Archived-At: Subject: Re: [dmarc-ietf] auth-res vs. dmarc X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Dec 2020 20:47:57 -0000 --00000000000021af5305b7a08163 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Dec 29, 2020 at 3:01 PM Michael Thomas wrote: > > On 12/29/20 11:35 AM, Todd Herr wrote: > > None of the validation checks bothered with the p=3D value in the > mrochek.com DMARC policy record, because the p=3D value is immaterial to > the validation check. Whether DMARC passes or fails is based on whether S= PF > or DKIM passes or fails with an aligned domain, full stop. > > Once the DMARC validation result is determined, then the mailbox provider= or entity performing the DMARC validation check can refer to the p=3D valu= e in determining how to dispose of the message, but it doesn't have to. It'= s worth noting perhaps that Google does record message disposition in the a= uth-res header, though: > > dmarc=3Dfail (p=3DNONE sp=3DNONE dis=3DNONE) header.from=3Dmrochek.com > > Unless those values in parens are a MUST requirement, the dmarc=3Dfail is > highly misleading. I haven't even seen any specification for the dmarc pa= rt > of auth res in rfc 7601, which may be part of the problem. I don't see a= ny > normative language which would update rfc7601 in dmarc with the syntax an= d > semantics of the dmarc field. > We're going to have to agree to disagree here. I had no hand in writing RFC 7601 or its predecessors, but I believe DMARC is covered under "Extension Methods" in section 2.7.6 (https://tools.ietf.org/html/rfc7601#section-2.7.= 6) and "Email Authentication Results Names" in section 6.6 ( https://tools.ietf.org/html/rfc7601#section-6.6), which references RFC 7489 section 11.2, which in turn defines pass, fail, temperror, and permerror as it pertains to DMARC. As for the parenthetical bits, I believe they too are covered in RFC 7601 section 2.7.6: Authentication method implementers are encouraged to provide adequate information, via message header field comments if necessary, to allow an MUA developer to understand or relay ancillary details of authentication results. For example, if it might be of interest to relay what data was used to perform an evaluation, such information could be relayed as a comment in the header field, such as: Authentication-Results: example.com; foo=3Dpass bar.baz=3Dblob (2 of 3 tests OK) And I think in this specific case that those bits are there for the consumption of the downstream parts of the Gmail infrastructure and Gmail-developed clients (it's Gmail's MTA that's inserting the header, after all). Other mailbox providers do things slightly differently, I suspect. > At the very least this needs to be straightened out because auth-res, to > Ned's earlier point, can have consumers in the form of MUA's. > The format/contents of an auth-res header and its impact on MUA development seem to be a bit off-charter for this working group, but I'll say that it might be a heavy lift to try to get major mailbox providers who run their own highly customized MTAs to comply with any effort to fully standardize. Their interpretations of the headers that they insert are done to optimize usage with their message storage infrastructure and their web and mobile clients, the latter of which the vast majority of their mailbox holders use. I don't think they have much incentive to standardize to make things easier for an open source MUA developer, but the MUA developer can probably cover most variations relatively easily with a simple bit of if-then-else logic based on the provider. --=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. --00000000000021af5305b7a08163 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
=20 =20 =20


On 12/29/20 11:35 AM, Todd Herr wrote:
=20
None of the validation checks bothered with the p=3D value in the mrochek.com DMARC policy record, because the p=3D value is immaterial to the validation check. Whether DMARC passes or fails is based on whether SPF or DKIM passes or fails with an aligned domain, full stop. 


Once the DMARC validatio=
n result is determined, then the mailbox provider or entity performing the =
DMARC validation check can refer to the p=3D value in determining how to di=
spose of the message, but it doesn't have to. It's worth noting per=
haps that Google does record message disposition in the auth-res header, th=
ough:


dmarc=3Dfail (p=3DNO=
NE sp=3DNONE dis=3DNONE) header.from=3Dmrochek.com
Unless those values in parens are a MUST requirement, the dmarc=3Dfail is highly misleading. I haven't even seen any specification for the dmarc part of auth res in rfc=C2=A0 7601, which may be part of the problem. I don't see any normative language which would update rfc7601 in dmarc with the syntax and semantics of the dmarc field.
=

We're going to have to agree to = disagree here. I had no hand in writing RFC 7601 or its predecessors, but I= believe DMARC is covered under "Extension Methods" in section 2.= 7.6 (https://= tools.ietf.org/html/rfc7601#section-2.7.6) and "Email Authenticati= on Results Names" in section 6.6 (https://tools.ietf.org/html/rfc7601#section-6.6= ), which references RFC 7489 section 11.2, which in turn defines pass, fail= , temperror, and permerror as it pertains to DMARC.

As for the parenthetical bits, I believe they too are covered in RFC 7601= section 2.7.6:

   Authentication method implementers are encouraged to p=
rovide adequate
   information, via message header field comments if necessary, to allow
   an MUA developer to understand or relay ancillary details of
   authentication results.  For example, if it might be of interest to
   relay what data was used to perform an evaluation, such information
   could be relayed as a comment in the header field, such as:

        Authentication-Results: example.com<=
/a>;
                  foo=3Dpass bar.baz=3Dblob (2 of 3 tests OK)

At the very least this needs to be straightened out because auth-res, to Ned's earlier point, can have consumers in the form of MUA's.


--

Todd He= rr | Sr. Technical Program Manager
p: 703= .220.4153


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

--00000000000021af5305b7a08163-- From nobody Tue Dec 29 12:59: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 656DE3A0A29 for ; Tue, 29 Dec 2020 12:59:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.85 X-Spam-Level: X-Spam-Status: No, score=-1.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iecc.com header.b=ewzkQ34I; dkim=pass (2048-bit key) header.d=taugh.com header.b=PHJe5g0N Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BIr-zcNbGgcP for ; Tue, 29 Dec 2020 12:59:25 -0800 (PST) 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 AE7173A0A22 for ; Tue, 29 Dec 2020 12:59:24 -0800 (PST) Received: (qmail 94126 invoked from network); 29 Dec 2020 20:59:23 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=16fac.5feb98ab.k2012; bh=E5P3QjT6PC+ieSZ+ePmb/tXEGj3rMZE7PynO8fZA8Rs=; b=ewzkQ34ImvRKNF0iAMYnEk2jx1ORu4G9myqWYUb//832YRroiAodGNPKO5mjYhq+jnQFKaVHXea2i4ZL/xXPf298yWKPeIsxvgKvdcTX7PfRxuMWeNvypoYhDkUF7aAWQ10MkyPL6jrYTXopk4i4pJL5NeiLlC2c19hS8UAffkftVU0pKdKhtRFaHcC/imRmvBh5FT3PHe/LoY65l4M6jMD9M2v5BrOVAdX4s/qu2fGRr004fIc3dlksfrzH8lPlbzACI3+M9kC40GtdUzPzRycp9EZVHh775ksU6+t/PHsgOoPJrShrsGGDWUH4RHz2r7+U8RfyoqVE0JVEf7L1oQ== DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=16fac.5feb98ab.k2012; bh=E5P3QjT6PC+ieSZ+ePmb/tXEGj3rMZE7PynO8fZA8Rs=; b=PHJe5g0NG8SK5ylj2st/pqHPOO/B4eMifLtoTW8ndeGw0zWRyoK/C603eDcVxQ5lKy8Gx+mEH7HXxVQmZL7HBMRKKjX3DyVVJyKb+oJX1UMjd0XMWSMVJUmaSKYfDCDt8DNbr4EkN61OkXck4K9aOzeSlfd3y7p6puQN4uD1vBDOvpqVSgi+6kAbeCCwJpcKisFoDSH5C79P4Mw/5+zBMqZSo4m1sq9JJzEeg2AkJWUjl2UDt9DSWrM26X8gNqo+dROwOlwNMJ8AQsP9ozlOtmFPO24me7eXvpjVPZxOqUmZjoK8Nvo+ZImdz7dO8saqyUtoy7OamaZo4K8j7nKEgg== 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; 29 Dec 2020 20:59:23 -0000 Received: by ary.qy (Postfix, from userid 501) id BD91635185C5; Tue, 29 Dec 2020 15:59:22 -0500 (EST) Date: 29 Dec 2020 15:59:22 -0500 Message-Id: <20201229205922.BD91635185C5@ary.qy> From: "John Levine" To: dmarc@ietf.org Cc: mike@mtcc.com In-Reply-To: <14d833ce-0ae0-f818-fd4f-95769266a8e0@mtcc.com> Organization: Taughannock Networks X-Headerized: yes Cleverness: minimal Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] Ticket #55 - Clarify legal and privacy implications of failure reports X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Dec 2020 20:59:26 -0000 In article <14d833ce-0ae0-f818-fd4f-95769266a8e0@mtcc.com> you write: > >On 12/29/20 12:10 PM, John Levine wrote: >> A lot of tiny non-profits like Girl Scout troops use email addresses >> at webmail providers and send their announcements through ESPs like >> Constant Contact and Mailchimp. This is yet another situation where >> DMARC can't describe an entirely normal mail setup. >> >> Constant Contact apparently got Yahoo to give them a signing key, >> at least temporarily, but that doesn't scale. > >What gmail does for gsuite is generates (or not, who knows) a key and >gives you the selector to add to your dns. I don't see why that doesn't >scale for all situations. To point out the obvious, because they use a single address at yahoo.com or gmail.com or hotmail.com, not a private domain. These are tiny organizations that don't have a lot of computer expertise nor a lot of need for it. From nobody Tue Dec 29 13:02: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 E1CE23A0A2E for ; Tue, 29 Dec 2020 13:02:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, 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=mtcc.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 aTQk7TcNP9bd for ; Tue, 29 Dec 2020 13:02:24 -0800 (PST) Received: from mail-pl1-x636.google.com (mail-pl1-x636.google.com [IPv6:2607:f8b0:4864:20::636]) (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 186E73A0A29 for ; Tue, 29 Dec 2020 13:02:23 -0800 (PST) Received: by mail-pl1-x636.google.com with SMTP id 4so7680943plk.5 for ; Tue, 29 Dec 2020 13:02:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mtcc.com; s=fluffulence; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=1SSwX6IGi9RhJhy9WUjeVxkYxQBtBb5eF8IjaFZrFEw=; b=kJM3e3MUfpV900dfBr4PW1AQ/Ng9Lov6VRnKcBqvHRwdYdnmQGAZPnMOAja0V22ylF OH8wZy3Ml2SuwjdqOAL5lnnOgKqpK4ODM5L8OfXOo+vLM1ojeO3zz/YE/2HW0ijTVOPB eMnQVKb39L6F7FBdpH4hr95aOasa/f16hSL/KNpPEFTCn47uOaDuEEEA1u+Qfa+UhavP Ru/JpNFAshuUdTfBnXTf5EPRHEafc3wtyBlqzrKqOuZUvDGllfXsrLwB/Y4z7zInMrEt Xys/iSDscvn4TO3o16WO7X9a1SMy6lcSPIKjv7rC0WbwGS9JZrXjGpGVmGPSi+JjLWI+ ZFew== 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=1SSwX6IGi9RhJhy9WUjeVxkYxQBtBb5eF8IjaFZrFEw=; b=k0yYbkss5akhq8tCHKu88jswT0fVC7/2BI/dxiz44ud+nM/6Zt6nTdt1SnbgHTofQN eLf7Ti9vpjewAEiI7bmdmoIsQND4sJ+l/aoNY0FDJMlyD5NTjl1Rv7JkEooUSl6bnVSH MzvLxToEKT/NKjRf+PTRLj7LXgfcwsQjNooAr/nXFAPaewfF2H1VPx+VkBTgBQpTU6sn rfCq5n3Aoab7E6U8JFyipWp51eUR2oJf+LxtyP023pq53BV3MPJCYDEK0n9iWoinRqXL TD3G73QM1zdVzj8IoFDWjiT/c9MoMGvtijt3hYa8G6vZuQGITe3WOrocPhPCObJJdQnh FBZQ== X-Gm-Message-State: AOAM533lMzOw6mJcGO1Lgyc9x9RXfxhsMBTUcgARxTZ8tBmm8zD3Fpnv VBZNHL58WypW60E5FveAeYgOpA31rmf65A== X-Google-Smtp-Source: ABdhPJw3tj83bDcvdqlIBhYCxYwfcQPUglT5U+7QmfLKf0AzDDu23pwsXOigiZcOgh9ZXoRY8OdFIA== X-Received: by 2002:a17:90a:8c87:: with SMTP id b7mr5787277pjo.158.1609275743013; Tue, 29 Dec 2020 13:02:23 -0800 (PST) Received: from mike-mac.lan ([107.182.37.0]) by smtp.gmail.com with ESMTPSA id u12sm39902786pfh.98.2020.12.29.13.02.21 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 29 Dec 2020 13:02:22 -0800 (PST) To: dmarc@ietf.org References: <9f6782b1-e85b-1a9c-9151-98feff7e18ea@mtcc.com> <140485eb-020f-4406-3f2f-e2c475ea51e5@mtcc.com> <5588dbbe-b876-ed80-c80f-792380e3718f@mtcc.com> <54dd9978-bcd1-6757-ad27-dcef6db6e5f7@mtcc.com> From: Michael Thomas Message-ID: <937f1019-a028-308d-2a0f-1e720fd49dcd@mtcc.com> Date: Tue, 29 Dec 2020 13:02:20 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------32C2FC44DE6A98656AFC2B23" Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] auth-res vs. dmarc X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Dec 2020 21:02:26 -0000 This is a multi-part message in MIME format. --------------32C2FC44DE6A98656AFC2B23 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 12/29/20 12:47 PM, Todd Herr wrote: > Unless those values in parens are a MUST requirement, the dmarc=fail > is highly misleading. I haven't even seen any specification for the > dmarc part of auth res in rfc  7601, which may be part of the problem. > I don't see any normative language which would update rfc7601 in dmarc > with the syntax and semantics of the dmarc field. > > We're going to have to agree to disagree here. I had no hand in > writing RFC 7601 or its predecessors, but I believe DMARC is covered > under "Extension Methods" in section 2.7.6 > (https://tools.ietf.org/html/rfc7601#section-2.7.6 > ) and "Email > Authentication Results Names" in section 6.6 > (https://tools.ietf.org/html/rfc7601#section-6.6 > ), which references > RFC 7489 section 11.2, which in turn defines pass, fail, temperror, > and permerror as it pertains to DMARC. > > As for the parenthetical bits, I believe they too are covered in RFC > 7601 section 2.7.6: > > Authentication method implementers are encouraged to provide adequate > information, via message header field comments if necessary, to allow > an MUA developer to understand or relay ancillary details of > authentication results. For example, if it might be of interest to > relay what data was used to perform an evaluation, such information > could be relayed as a comment in the header field, such as: > > Authentication-Results:example.com ; > foo=pass bar.baz=blob (2 of 3 tests OK) So Google is just adding an informative comment which is free style text that just happens to have the juicy bits (the interesting parts dmarc record), which cannot be counted on. So that's useless for the MUA trying to use auth-res. You would never display a DMARC FAIL or fail of any kind for p=none. It doesn't make sense to the user. Likewise, even if we're talking about a downstream MTA parsing the auth-res, it will be useless to it as well because it has the same problem not knowing the context of the "failure". > At the very least this needs to be straightened out because > auth-res, to Ned's earlier point, can have consumers in the form > of MUA's. > > The format/contents of an auth-res header and its impact on MUA > development seem to be a bit off-charter for this working group, but > I'll say that it might be a heavy lift to try to get major mailbox > providers who run their own highly customized MTAs to comply with any > effort to fully standardize. Their interpretations of the headers that > they insert are done to optimize usage with their message storage > infrastructure and their web and mobile clients, the latter of which > the vast majority of their mailbox holders use. I don't think they > have much incentive to standardize to make things easier for an open > source MUA developer, but the MUA developer can probably cover most > variations relatively easily with a simple bit of if-then-else logic > based on the provider. > To Ned's point though: what is auth-res's purpose and why is it standard track if it can't provide a complete encapsulation of the state of authentication necessary for downstream consumers? For DMARC in particular, it falls far short since there is no way of knowing the policy. I do think that's DMARC's problem to solve somehow, regardless of process. And if process is a problem, that's processes fault. Mike, coming at completely from the standpoint of modifying thunderbird plugin code --------------32C2FC44DE6A98656AFC2B23 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit


On 12/29/20 12:47 PM, Todd Herr wrote:
Unless those values in parens are a MUST requirement, the dmarc=fail is highly misleading. I haven't even seen any specification for the dmarc part of auth res in rfc  7601, which may be part of the problem. I don't see any normative language which would update rfc7601 in dmarc with the syntax and semantics of the dmarc field.

We're going to have to agree to disagree here. I had no hand in writing RFC 7601 or its predecessors, but I believe DMARC is covered under "Extension Methods" in section 2.7.6 (https://tools.ietf.org/html/rfc7601#section-2.7.6) and "Email Authentication Results Names" in section 6.6 (https://tools.ietf.org/html/rfc7601#section-6.6), which references RFC 7489 section 11.2, which in turn defines pass, fail, temperror, and permerror as it pertains to DMARC.

As for the parenthetical bits, I believe they too are covered in RFC 7601 section 2.7.6:

   Authentication method implementers are encouraged to provide adequate
   information, via message header field comments if necessary, to allow
   an MUA developer to understand or relay ancillary details of
   authentication results.  For example, if it might be of interest to
   relay what data was used to perform an evaluation, such information
   could be relayed as a comment in the header field, such as:

        Authentication-Results: example.com;
                  foo=pass bar.baz=blob (2 of 3 tests OK)

So Google is just adding an informative comment which is free style text that just happens to have the juicy bits (the interesting parts dmarc record), which cannot be counted on. So that's useless for the MUA trying to use auth-res. You would never display a DMARC FAIL or fail of any kind for p=none. It doesn't make sense to the user. Likewise, even if we're talking about a downstream MTA parsing the auth-res, it will be useless to it as well because it has the same problem not knowing the context of the "failure".


At the very least this needs to be straightened out because auth-res, to Ned's earlier point, can have consumers in the form of MUA's.

The format/contents of an auth-res header and its impact on MUA development seem to be a bit off-charter for this working group, but I'll say that it might be a heavy lift to try to get major mailbox providers who run their own highly customized MTAs to comply with any effort to fully standardize. Their interpretations of the headers that they insert are done to optimize usage with their message storage infrastructure and their web and mobile clients, the latter of which the vast majority of their mailbox holders use. I don't think they have much incentive to standardize to make things easier for an open source MUA developer, but the MUA developer can probably cover most variations relatively easily with a simple bit of if-then-else logic based on the provider.

To Ned's point though: what is auth-res's purpose and why is it standard track if it can't provide a complete encapsulation of the state of authentication necessary for downstream consumers? For DMARC in particular, it falls far short since there is no way of knowing the policy. I do think that's DMARC's problem to solve somehow, regardless of process. And if process is a problem, that's processes fault.

Mike, coming at completely from the standpoint of modifying thunderbird plugin code

--------------32C2FC44DE6A98656AFC2B23-- From nobody Tue Dec 29 13:05: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 7E6DA3A0A3B for ; Tue, 29 Dec 2020 13:05:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, 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=mtcc.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 ers6lZAmlJgW for ; Tue, 29 Dec 2020 13:05:33 -0800 (PST) Received: from mail-pl1-x630.google.com (mail-pl1-x630.google.com [IPv6:2607:f8b0:4864:20::630]) (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 B19B13A0A2E for ; Tue, 29 Dec 2020 13:05:33 -0800 (PST) Received: by mail-pl1-x630.google.com with SMTP id be12so7691414plb.4 for ; Tue, 29 Dec 2020 13:05:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mtcc.com; s=fluffulence; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=kD0WKcj7ZEGFGVXq7PVhB+fTPugB0szZhvWNzUvbIB8=; b=VVsHn1orcPDZbSFjkKQp9rI9zkgKCHwvfDN1WIvRn6ujAvDFP7Be9fZNuLPxt/LejL KZKkqcExU8uLdtENcMM31liiwUp17fWMFB86EuWB7AuWCPs56ZzyoC5uTH2EdEacexx4 6t3fr+Ti5m4w4sCbCZ71EwQOyW6Vr9pK1hSgXFSunJ2K6wIcdFrBNug8U4zvRgkwVZU7 2YF9jcOJCq3kOH3CBfUhmHFdDI57Cu7phq6FZtjir+8FSeoEaItB+4pwEpzdbMCDldPW pzX8d0dbMwyqmfMPYcZSlzKTPjs7NyTyRk498UHAqkzS7Mta4Ps3InFjhkOjX8o2QgS+ Uxfg== 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=kD0WKcj7ZEGFGVXq7PVhB+fTPugB0szZhvWNzUvbIB8=; b=tJ4pooLBYXk1JNowAw2aCeT/hNL+1CGQ8Wfij0/BK2Il5H55X/4vmsS1e70MyAafm9 Sfi8J0WiXVhjNac5uzxQkq6Z/z7+oDNKoKS11kncrqrNEepQRN2+Yf2QLG3lERXkCNar TPQJYkQCTWW/U0PbvaMTzS7mvNKxLfze3vk9US7QHCIDnvBh7PUTfn3oBL8iMD2Szfia dfOWLtmIshWBlcTj2G7kB7H4OY+mZ5oP9viaJ7LIeT7fJRMXlEZqxMQuZuxfNKXhNYMr NFbZ24r57LZFn/kdsrRZiU/CgHFY+s7d4DiOBJXYQcwokfkve/PbIUpDhy2+e1UHm0/E QUsw== X-Gm-Message-State: AOAM5334kFqsVhfdDrCxUnc3Xj0cil7bGMyZdSAC4ipm3q/KtAX1aXdv RNgnF4J/ITtUzuWrxPd7djcr8O8Sqn1WXg== X-Google-Smtp-Source: ABdhPJzTTeIHw6j5r2pgx0rq+ps5zh8V/K4Nmos2jHIg+EyqmVR2Le7TwSrlIEBxy2BzzuNVgHEExA== X-Received: by 2002:a17:90a:398d:: with SMTP id z13mr5636777pjb.1.1609275932665; Tue, 29 Dec 2020 13:05:32 -0800 (PST) Received: from mike-mac.lan ([107.182.37.0]) by smtp.gmail.com with ESMTPSA id q35sm4201029pjh.38.2020.12.29.13.05.31 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 29 Dec 2020 13:05:32 -0800 (PST) To: John Levine , dmarc@ietf.org References: <20201229205922.BD91635185C5@ary.qy> From: Michael Thomas Message-ID: <17f3ed7e-2fbe-48fd-d6c0-d394d06abb43@mtcc.com> Date: Tue, 29 Dec 2020 13:05:30 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: <20201229205922.BD91635185C5@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] Ticket #55 - Clarify legal and privacy implications of failure reports X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Dec 2020 21:05:35 -0000 On 12/29/20 12:59 PM, John Levine wrote: > In article <14d833ce-0ae0-f818-fd4f-95769266a8e0@mtcc.com> you write: >> On 12/29/20 12:10 PM, John Levine wrote: >>> A lot of tiny non-profits like Girl Scout troops use email addresses >>> at webmail providers and send their announcements through ESPs like >>> Constant Contact and Mailchimp. This is yet another situation where >>> DMARC can't describe an entirely normal mail setup. >>> >>> Constant Contact apparently got Yahoo to give them a signing key, >>> at least temporarily, but that doesn't scale. >> What gmail does for gsuite is generates (or not, who knows) a key and >> gives you the selector to add to your dns. I don't see why that doesn't >> scale for all situations. > To point out the obvious, because they use a single address at > yahoo.com or gmail.com or hotmail.com, not a private domain. These are > tiny organizations that don't have a lot of computer expertise nor a > lot of need for it. Um, so? The have to procure a domain too which can be technically challenging. If they want to use outsourced email, the outsourced email provider should provide the support to get their selector into their DNS.  If they can't bother, I don't care if their email isn't delivered. Mike From nobody Tue Dec 29 17:30: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 8035D3A0D9B for ; Tue, 29 Dec 2020 17:30:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4pd1iVXEQVR9 for ; Tue, 29 Dec 2020 17:30:51 -0800 (PST) Received: from mail-vk1-xa2f.google.com (mail-vk1-xa2f.google.com [IPv6:2607:f8b0:4864:20::a2f]) (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 719873A0D99 for ; Tue, 29 Dec 2020 17:30:51 -0800 (PST) Received: by mail-vk1-xa2f.google.com with SMTP id m145so3346379vke.7 for ; Tue, 29 Dec 2020 17:30:51 -0800 (PST) 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=GzMkzgWpf+iIhWZ91NVF7t6OqfII0poo7yYwisFEqis=; b=ZpP9Y9WQqnbEEvGfBvFkNdoSfa2PmpQ5hXXwmI4aE4cWxt1Uk8pMRVEDKg41VhWtk9 f+S/W7zJ8EZsGhDsb5efqbuzAZDOY0cS1+vnBxEZINaKJajInCwryzsJgeFclp6sU8O0 XLOTHEhxNYfgVRn+3gQK1+EuAQRUScQzh0u2tOmtNiKEXFKcWYFiAa5ReaxOj5TqmiiN 216/e61ukORCQq/PQq1tsN3SrdbeLZHbvvUrEya/EmIodMHYn6s9QRznYN//L/0mW4LW +J8AtpmB8HeAUjaOPuaRWuP0pA1JJ5CpfyQTY4fsRmZs13y6gcsmCjLhLUYykyfooTdf fYng== 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=GzMkzgWpf+iIhWZ91NVF7t6OqfII0poo7yYwisFEqis=; b=srHhECN6o0dxodUv0GUaak+e0YDAgqggEJBaqBaT2byxSvW40LpHxX3FXNfjhYd5hU V2Hf/y2zM7gcI6M0UsRh2wCYWqlbF5xaIVZU8aK0Sxu0xgcyVUlC4n+LnmzsjjzKm2UX XfuwyrKgJRNV1ZJyFHtWd+8MhlwK0AIj2w9/xEGR+P3/0/zXa3OpGxm6e27MKsXkpfAF SXEGtSdMXxar1HzSr4NaiQMZhTiWj1SjucwD+cLZK/5FStYPoGvOL6F0Rj+UbMT60XRV 1hrGu0s+Krd+989dca+oqLawfiQ82gUHO8oVeieOtFevg6nwlJMBIhLtAtRaBQDhliZm RkeQ== X-Gm-Message-State: AOAM530UMRWKbU4iACxoXCABrxCfhJBaK+rIrTAOfvxeRWbvFyP0FDq/ VM2W7h2KZOKmtUBzXZqqIZgLdPaC+Vvwdf2r5k5cK9aZcbU= X-Google-Smtp-Source: ABdhPJzadgJeAbOxUzxu2v4kCzKd/CCrQvuSXKmaBmf01MWjVz3YqZ3yplNE+IjM/1cofQCULdWJp5LV3OZLyfCreoM= X-Received: by 2002:a1f:20d1:: with SMTP id g200mr32696240vkg.25.1609291850221; Tue, 29 Dec 2020 17:30:50 -0800 (PST) MIME-Version: 1.0 References: <9f6782b1-e85b-1a9c-9151-98feff7e18ea@mtcc.com> <140485eb-020f-4406-3f2f-e2c475ea51e5@mtcc.com> <5588dbbe-b876-ed80-c80f-792380e3718f@mtcc.com> <54dd9978-bcd1-6757-ad27-dcef6db6e5f7@mtcc.com> In-Reply-To: From: Douglas Foster Date: Tue, 29 Dec 2020 20:30:40 -0500 Message-ID: To: IETF DMARC WG Content-Type: multipart/alternative; boundary="0000000000001293c005b7a47581" Archived-At: Subject: Re: [dmarc-ietf] auth-res vs. dmarc X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Dec 2020 01:30:54 -0000 --0000000000001293c005b7a47581 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I understand that Authentication-Results are intended for use within a single organization, since any assertion by an outsider could be malicious. Since IETF does not apply ARC Sets, we are using A-R as a proxy for what might be possible with ARC, but the two are different. I still see a problem with ARC or A-R. These headers assert, "These attributes had these statuses values when I saw them," but they do not reliably indicate when that look was performed. The typical message header set provides a list of address identifiers which have little connection to servers, and a list of server identifiers which have little connection to the address identifiers. Consider these results from a sample message from this list. They are presented in the order that they appear in the message headers (top might be newest.) The first two are A-R and the bottom one is ARC-A-R: ietfa.amsl.com (amavisd-new); dkim=3Dpass (2048-bit key) header.d=3D comcast.com ietf.org; dkim=3Dnone (message not signed) header.d=3Dnone;ietf.org; dmarc=3Dnone action=3Dnone header.from=3Dcomcast.com; i=3D1; mx.microsoft.com 1; spf=3Dpass smtp.mailfrom=3Dcomcast.com; dmarc=3Dpass action=3Dnone header.from=3Dcomcast.com; dkim=3Dpass header.d= =3D comcast.com; arc=3Dnone The bottom one tells me that an authenticator identified as " mx.microsoft.com 1" saw an SPF Pass, but I don't know what IP address it authenticated, and I don't know when this occurred. There are no Microsoft.Com servers in the Received header list, and the Auth-Ident is not intended to convey a server or domain identifier. The bottom entry says that the message passed DKIM, but the second entry tells me that there are no signatures at all, yett the third one assures me that the signatures have suddenly reappeared and are verifiable. DKIM, A-R, and ARC should all have a mandatory attribute indicating the HELO name of the server applying the header, the IP Address of the previous server which supplied the information being evaluated, or both. Without a link between the address identifiers and the server identifiers, I don't see how a viable algorithm can be constructed to use the data. Message forwarding provides so much opportunity to confuse the spam filters that I am surprised that the bad guys do not use it extensively. DF On Tue, Dec 29, 2020 at 3:01 PM Michael Thomas wrote: > > On 12/29/20 11:35 AM, Todd Herr wrote: > > None of the validation checks bothered with the p=3D value in the > mrochek.com DMARC policy record, because the p=3D value is immaterial to > the validation check. Whether DMARC passes or fails is based on whether S= PF > or DKIM passes or fails with an aligned domain, full stop. > > Once the DMARC validation result is determined, then the mailbox provider= or entity performing the DMARC validation check can refer to the p=3D valu= e in determining how to dispose of the message, but it doesn't have to. It'= s worth noting perhaps that Google does record message disposition in the a= uth-res header, though: > > dmarc=3Dfail (p=3DNONE sp=3DNONE dis=3DNONE) header.from=3Dmrochek.com > > Unless those values in parens are a MUST requirement, the dmarc=3Dfail is > highly misleading. I haven't even seen any specification for the dmarc pa= rt > of auth res in rfc 7601, which may be part of the problem. I don't see a= ny > normative language which would update rfc7601 in dmarc with the syntax an= d > semantics of the dmarc field. > > At the very least this needs to be straightened out because auth-res, to > Ned's earlier point, can have consumers in the form of MUA's. > > Mike > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > --0000000000001293c005b7a47581 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I understand that Authentication-Results are intended for = use within a single organization, since any assertion by an outsider could = be malicious.=C2=A0 =C2=A0
Since IETF does not apply ARC Sets, we are u= sing A-R as a proxy for what might be possible with ARC, but the two are di= fferent.

I still see a problem with ARC or A-R.=C2= =A0 These headers assert, "These attributes had these statuses values = when I saw them," but they do not reliably indicate when that look was= performed.=C2=A0 =C2=A0The typical message header set provides a list of a= ddress identifiers which have little connection to servers, and a list of s= erver identifiers which have little connection to the address identifiers.= =C2=A0 =C2=A0=C2=A0

Consider these results from a = sample message from this list.=C2=A0 =C2=A0They are presented in the order = that they appear in the message headers (top might be newest.)=C2=A0 =C2=A0= The first two are A-R and the bottom one is ARC-A-R:

=C2=A0 =C2=A0 =C2=A0ietfa.amsl.com= (amavisd-new); dkim=3Dpass (2048-bit key) header.d=3Dcomcast.com

=
=C2=A0 =C2=A0 =C2=A0ietf.org; dkim=3Dn= one (message not signed) header.d=3Dnone;ietf.o= rg; dmarc=3Dnone action=3Dnone header.from=3Dcomcast.com;

=C2= =A0 =C2=A0 =C2=A0i=3D1; mx.microsoft.co= m 1; spf=3Dpass smtp.mailfrom=3Dcomcast.= com; dmarc=3Dpass action=3Dnone header.from=3Dcomcast.com; dkim=3Dpass header.d=3Dcomcast.com; arc=3Dnone=C2=A0=C2=A0

The = bottom one tells me that an authenticator identified as "mx.microsoft.com 1" saw an SPF Pass, but I = don't know what IP address it authenticated, and I don't know when = this occurred.=C2=A0 There are no Microsoft.Com servers in the Received hea= der list,=C2=A0and the Auth-Ident is not intended to convey a server or dom= ain identifier.

The bottom entry says that the mes= sage passed DKIM, but the second entry tells me that there are no signature= s at all, yett the third one assures me that the signatures have suddenly r= eappeared and are verifiable.

DKIM, A-R, and ARC s= hould all have a mandatory attribute indicating the HELO name of the server= applying the header, the IP Address of the previous server which supplied = the information being evaluated,=C2=A0or both.=C2=A0 =C2=A0Without a link b= etween the address identifiers and the server identifiers, I don't see = how a viable algorithm can be constructed to use the data.

Message forwarding provides so much opportunity to confuse the spa= m filters that I am surprised that the bad guys do not use it extensively.<= /div>

DF


On Tue, Dec 29, 2020 at 3:0= 1 PM Michael Thomas <mike@mtcc.com&= gt; wrote:
=20 =20 =20


On 12/29/20 11:35 AM, Todd Herr wrote:
=20
None of the validation checks bothered with the p=3D value in the mrochek.com DMARC policy record, because the p=3D value is immaterial to the validation check. Whether DMARC passes or fails is based on whether SPF or DKIM passes or fails with an aligned domain, full stop. 


Once the DMARC validatio=
n result is determined, then the mailbox provider or entity performing the =
DMARC validation check can refer to the p=3D value in determining how to di=
spose of the message, but it doesn't have to. It's worth noting per=
haps that Google does record message disposition in the auth-res header, th=
ough:


dmarc=3Dfail (p=3DNO=
NE sp=3DNONE dis=3DNONE) header.from=3Dmrochek.com
Unless those values in parens are a MUST requirement, the dmarc=3Dfail is highly misleading. I haven't even seen any specification for the dmarc part of auth res in rfc=C2=A0 7601, which may be part of the problem. I don't see any normative language which would update rfc7601 in dmarc with the syntax and semantics of the dmarc field.

At the very least this needs to be straightened out because auth-res, to Ned's earlier point, can have consumers in the form of MUA's.

Mike

_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
--0000000000001293c005b7a47581-- From nobody Tue Dec 29 18:50: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 68D2D3A0E0B for ; Tue, 29 Dec 2020 18:50:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=drkurt.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hto_MbWWIqnq for ; Tue, 29 Dec 2020 18:50:27 -0800 (PST) Received: from mail-il1-x136.google.com (mail-il1-x136.google.com [IPv6:2607:f8b0:4864:20::136]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6B753A0E0A for ; Tue, 29 Dec 2020 18:50:27 -0800 (PST) Received: by mail-il1-x136.google.com with SMTP id n9so13783651ili.0 for ; Tue, 29 Dec 2020 18:50:27 -0800 (PST) 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=fhZBNz2Ysj42q0wc5Ls3mZCldSZN+1ziIjK4mrCo+So=; b=K+AnSO2/Zi6Tq6bVOraMjDeoJZNaywoVYiA0Co+HqZuOX8YKxXc5DR4UfDu2zuQpzh 3/sRYcnuWL24+IDMxs8S7+0xDyKiJAMkljWJMvRHs0U2GwFTsFpFwQnIEm5sjePMIvca PiGO3/UUXh/vygcL0Z0tT7Vl1RhzHV+hRQ5bs= 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=fhZBNz2Ysj42q0wc5Ls3mZCldSZN+1ziIjK4mrCo+So=; b=g74onRgPrVQZ1h9MoDwK3AJPk8UTUFu3UY8ln+UICA2Df3roXb5PRS+FP65IGpuiE5 H1xhHgJ3Opmolkg+ZTE6/l9q4aFQacbx0n0ex2xF5izq4VCyWtAZHE1Rti8aJo6vPzpN fwSidKBVTJ7wnWB8zQFOW1bNJiHWP2T53vDe6IIq/4+Deb6MmNLJgkdagHkvQB9rX4vK oMDgxpcF8rG3509TF8NM5tZvyo2REowpXuRtmQ6N1Tx60pr2djPXyt2FJLOcUAPWK0ia jzccBSsddTZkvI66+d3s89Wj5UleHHwVwuZXmdH7YvRQyMPs8TFBAtYnverL8yvygJg6 csBA== X-Gm-Message-State: AOAM530vvFSby7gqMbtTTW7fApWeiCPXvgKRZ0g1g8WNmftnyO1Wd21r yrDC/J38+kJK30ouYyXQ9Nw+yuiQEP71Jxr2egTP2IdcCYKXPw== X-Google-Smtp-Source: ABdhPJxKz2b4TYw488LAyzcXPX/WuERgXJX/Mvwck4X1YuAIYPrtnvOSyOGbBMOOJxxBoH46tutRTrhx1auR+t95K2c= X-Received: by 2002:a05:6e02:12cc:: with SMTP id i12mr51368866ilm.23.1609296627066; Tue, 29 Dec 2020 18:50:27 -0800 (PST) MIME-Version: 1.0 References: <9f6782b1-e85b-1a9c-9151-98feff7e18ea@mtcc.com> <140485eb-020f-4406-3f2f-e2c475ea51e5@mtcc.com> <5588dbbe-b876-ed80-c80f-792380e3718f@mtcc.com> <54dd9978-bcd1-6757-ad27-dcef6db6e5f7@mtcc.com> In-Reply-To: From: "Kurt Andersen (b)" Date: Tue, 29 Dec 2020 18:50:16 -0800 Message-ID: To: Douglas Foster Cc: IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000cb806f05b7a5912e" Archived-At: Subject: Re: [dmarc-ietf] auth-res vs. dmarc X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Dec 2020 02:50:29 -0000 --000000000000cb806f05b7a5912e Content-Type: text/plain; charset="UTF-8" On Tue, Dec 29, 2020 at 5:31 PM Douglas Foster < dougfoster.emailstandards@gmail.com> wrote: > > DKIM, A-R, and ARC should all have a mandatory attribute indicating the > HELO name of the server applying the header, the IP Address of the previous > server which supplied the information being evaluated, or both. > With all due respect, it seems to me like this is something which should have been pointed out before this WG came to final consensus on 8601 (aka 7601bis). A-R and AAR were not designed to be fed into a determinative state machine. --Kurt --000000000000cb806f05b7a5912e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Dec 29, 2020 at 5:31 PM Douglas F= oster <dougfoster= .emailstandards@gmail.com> wrote:
<= br>
DKIM, A-R, and ARC should all have a mandatory attribute indi= cating the HELO name of the server applying the header, the IP Address of t= he previous server which supplied the information being evaluated,=C2=A0or = both.=C2=A0 =C2=A0

With all due= respect, it seems to me like this is something which should have been poin= ted out before this WG came to final consensus on 8601 (aka 7601bis). A-R a= nd AAR were not designed to be fed into a determinative state machine.

--Kurt=C2=A0
--000000000000cb806f05b7a5912e-- From nobody Tue Dec 29 19:43: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 E1BE53A0EA0 for ; Tue, 29 Dec 2020 19:43:08 -0800 (PST) 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 hOr-ZZq2lwdM for ; Tue, 29 Dec 2020 19:43:07 -0800 (PST) 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 313623A0CE6 for ; Tue, 29 Dec 2020 19:43:07 -0800 (PST) Received: by mail-vs1-xe2c.google.com with SMTP id x4so8018102vsp.7 for ; Tue, 29 Dec 2020 19:43:07 -0800 (PST) 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=Ea+93L8LBDUxAHh7fUnsRZ+UgIFHJYjJB90Gf1IJnQI=; b=tWGEt9gU4K1GVoPqHvvM2Z07zhfgORpdRKMf4CU9Ti/JbLkuT4/p7DqyVQM/yRNaxb QIwsT5OQ9ukYvFAofJk97Lewq0zUa6mOok1Tj+2M87gkcUhUsrv79bRgjI6F5mdemfeU Xf7p3egB0xx7DCoCcXMKw+sRlg6Mm4CDL8lSJglXiDLwyzFg25kS9ah7IBYK3MoMlfPM mtd6hy6iGPY1sVUxQlobAI7JqklUz+5Qw8+9VJhBkQCleSWbNcHdfh8sCDzbmQyVl/OI tyIFfq5kYXQFxuk96exh3KBI9zwUxCL4CmvqNzLdi13k0VkpMCMVZ2cYh0vu0Tdla8sN CVkw== 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=Ea+93L8LBDUxAHh7fUnsRZ+UgIFHJYjJB90Gf1IJnQI=; b=I7t7n09gNp/khI2GylEqRsDi6rSHk+JRZ23hn+ydkI/MBE10O9MB8oVJg4znH5hl8k 5l8Ed/ROFZi9eJ7uyrdTru9ev9IkmGI73J8H+on7huGitjd4Silz2vsnHUOWcsZ16IO5 JDZqu0oQ8U6MB9tNO1Xr+n22P5vsixmhhCcHg29nvPetRmACd+qkO4ZrrXyK78gMCrV0 I2ziBT1cN2l6lThdiq0sv6ytZ8+uJEDxQIvOUTBQnF2Olap63g2isZj1vAVfIQk8fi0b umTGuX9MCofcnBwQm/8Pn8gQxQoOOTeV45U3Z4JKdZqepdam8uJPd4g0+VA7K0xIUrKD d2AA== X-Gm-Message-State: AOAM530Sh0cDjUujo97OvhDjjgXoAgyVKkcJ6Kmy2uXy+1YauOEO8p1j wwlNyXE84qmz1/15yF4AF1RIKJbXwfoXsde8BJg= X-Google-Smtp-Source: ABdhPJwTG2J+E0pADP89QKO7/KGIwFU9+VnDyj271s8Ai/VTvcZG7Y1fLNwssOhVu8RCbwUGeX0DjRsjAN7dkzhmeJk= X-Received: by 2002:a67:507:: with SMTP id 7mr31881180vsf.42.1609299785391; Tue, 29 Dec 2020 19:43:05 -0800 (PST) MIME-Version: 1.0 References: <9f6782b1-e85b-1a9c-9151-98feff7e18ea@mtcc.com> <140485eb-020f-4406-3f2f-e2c475ea51e5@mtcc.com> <5588dbbe-b876-ed80-c80f-792380e3718f@mtcc.com> <54dd9978-bcd1-6757-ad27-dcef6db6e5f7@mtcc.com> In-Reply-To: From: Douglas Foster Date: Tue, 29 Dec 2020 22:42:55 -0500 Message-ID: To: "Kurt Andersen (b)" Cc: IETF DMARC WG Content-Type: multipart/alternative; boundary="0000000000000ba2d005b7a64eab" Archived-At: Subject: Re: [dmarc-ietf] auth-res vs. dmarc X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Dec 2020 03:43:09 -0000 --0000000000000ba2d005b7a64eab Content-Type: text/plain; charset="UTF-8" Does it help if I agree with you that it should have been brought up? To your implicit question, I did not bring it up because I was not involved at the time. On the other hand, that effort did not expect an A-R to be used outside of one ADMD, so the need for source identification was not obvious. ARC introduces the idea that A-R data might be useful outside of a single ADMD, so ARC is the opportunity to identify the data needed for this to be workable. ARC is still experimental, not standards-track. DMARCbis has forced recognition that indirect messages require different filtering algorithms than direct messages. To create those algorithms, it should be axiomatic that we need to be able to distinguish direct messages from indirect messages. Having done so, we need to extract the additional information needed to apply a differentiated algorithm correctly. I am simply an individual contributor trying to figure out how to use this stuff to correctly filter incoming mail. Show me how to correctly evaluate a forwarded message without understanding state sequence, and I will be happy to imitate someone else's success. Doug Foster On Tue, Dec 29, 2020, 9:50 PM Kurt Andersen (b) wrote: > On Tue, Dec 29, 2020 at 5:31 PM Douglas Foster < > dougfoster.emailstandards@gmail.com> wrote: > >> >> DKIM, A-R, and ARC should all have a mandatory attribute indicating the >> HELO name of the server applying the header, the IP Address of the previous >> server which supplied the information being evaluated, or both. >> > > With all due respect, it seems to me like this is something which should > have been pointed out before this WG came to final consensus on 8601 (aka > 7601bis). A-R and AAR were not designed to be fed into a determinative > state machine. > > --Kurt > --0000000000000ba2d005b7a64eab Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Does it help if I agree with you that it should have = been brought up?=C2=A0=C2=A0

To your implicit ques= tion, I did not bring it up because I was not involved at the time.=C2=A0 O= n the other hand, that effort did not expect an A-R to be used outside of o= ne ADMD, so the need for source identification was not obvious.=C2=A0=C2=A0=

ARC introduces the idea that A-R data might be us= eful outside of a single ADMD, so ARC is the opportunity to identify the da= ta needed for this to be workable.=C2=A0 =C2=A0ARC is still experimental, n= ot standards-track.

DMARCbis has forced recognitio= n that indirect messages require different filtering algorithms than direct= messages.=C2=A0 To create those algorithms, it should be axiomatic that we= need to be able to distinguish direct messages from indirect messages.=C2= =A0 Having done so, we need to extract the additional information needed to= apply a differentiated algorithm correctly.

I am = simply an individual contributor trying to figure out how to use this stuff= to correctly filter incoming mail.=C2=A0 Show me how to correctly evaluate= a forwarded message without understanding state sequence, and I will be ha= ppy to imitate someone else's success.

Doug Fo= ster




On Tue, Dec 29, 2020= , 9:50 PM Kurt Andersen (b) <kboth@drkurt.com> wrote:
On Tue, Dec 2= 9, 2020 at 5:31 PM Douglas Foster <dougfoster.emailstan= dards@gmail.com> wrote:

<= div>DKIM, A-R, and ARC should all have a mandatory attribute indicating the= HELO name of the server applying the header, the IP Address of the previou= s server which supplied the information being evaluated,=C2=A0or both.=C2= =A0 =C2=A0

With all due respect= , it seems to me like this is something which should have been pointed out = before this WG came to final consensus on 8601 (aka 7601bis). A-R and AAR w= ere not designed to be fed into a determinative state machine.
--Kurt=C2=A0
--0000000000000ba2d005b7a64eab-- From nobody Wed Dec 30 00:58: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 922573A02BD for ; Wed, 30 Dec 2020 00:58:04 -0800 (PST) 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, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 o0eGfwyAO6Ev for ; Wed, 30 Dec 2020 00:58:03 -0800 (PST) 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 4AD853A017E for ; Wed, 30 Dec 2020 00:58:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1609318679; bh=thOC9ukdPq3TFCzK6wrCiduFgWmyJejy1EpOHWYO6EA=; l=446; h=To:References:From:Date:In-Reply-To; b=AyO8QyyAwHKyooBR8sHSRrtG4oajPwPrikTRmYKuSxR04IYc5e1EZEXAo+u1xUoap pSoYP2Zcaayp+Tnr4KTy3iVMQ1HpIgEAN6VmfGbs0CA67U3xiPAyWdezltuKIeGE0B yvqxIBwsbPiSN+CaY0OpyxufNJsTyJCDpF6s2oJ92qleW9owqvsFEGgdTd9fd Authentication-Results: tana.it; auth=pass (details omitted) Original-From: Alessandro Vesely 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.000000005FEC4117.000022DC; Wed, 30 Dec 2020 09:57:59 +0100 To: dmarc@ietf.org References: <9f6782b1-e85b-1a9c-9151-98feff7e18ea@mtcc.com> <140485eb-020f-4406-3f2f-e2c475ea51e5@mtcc.com> <5588dbbe-b876-ed80-c80f-792380e3718f@mtcc.com> <54dd9978-bcd1-6757-ad27-dcef6db6e5f7@mtcc.com> From: Alessandro Vesely Message-ID: Date: Wed, 30 Dec 2020 09:57:57 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.6.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] auth-res vs. dmarc X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Dec 2020 08:58:05 -0000 On Wed 30/Dec/2020 02:30:40 +0100 Douglas Foster wrote: > DKIM, A-R, and ARC should all have a mandatory attribute indicating the HELO > name of the server applying the header, the IP Address of the previous server > which supplied the information being evaluated, or both. For DKIM, the HELO name is irrelevant. d= determines who did the deed. A-R and ARC have an authserv-id which is often consistent with HELO. Best Ale -- From nobody Wed Dec 30 01:42: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 486DE3A0813 for ; Wed, 30 Dec 2020 01:42:43 -0800 (PST) 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, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 myhAXwh48sE1 for ; Wed, 30 Dec 2020 01:42:41 -0800 (PST) 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 717E93A0809 for ; Wed, 30 Dec 2020 01:42:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1609321357; bh=2JWhCk+UCrEA3k7tELRe7waMj+Jd7l4Osrc5Pcaw6Yc=; l=2402; h=To:References:From:Date:In-Reply-To; b=BcDEaLfS3aZiWahEdNhOmn73RTKBacxlt/sLL5Ngmieizdyaj3TfBPHeBx91IFUsw 23+AD4nOAwVGmohDA+iqHmDbUeS0S6dEdFM6oeUl9bnU2MVnOdDaQt4L3QBmtQBE3J F2YHSaicMrpTA6ePdjYrm0m3bUnIWR2aaRSXpmnENr3gSd+bNfkvQh0XxOQmo Authentication-Results: tana.it; auth=pass (details omitted) Original-From: Alessandro Vesely Received: from [172.25.197.111] (pcale.tana [172.25.197.111]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLS1.3, 128bits, ECDHE_RSA_AES_128_GCM_SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC0CE.000000005FEC4B8D.0000283E; Wed, 30 Dec 2020 10:42:37 +0100 To: dmarc@ietf.org References: <9f6782b1-e85b-1a9c-9151-98feff7e18ea@mtcc.com> <140485eb-020f-4406-3f2f-e2c475ea51e5@mtcc.com> <5588dbbe-b876-ed80-c80f-792380e3718f@mtcc.com> <54dd9978-bcd1-6757-ad27-dcef6db6e5f7@mtcc.com> <937f1019-a028-308d-2a0f-1e720fd49dcd@mtcc.com> From: Alessandro Vesely Message-ID: Date: Wed, 30 Dec 2020 10:42:36 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: <937f1019-a028-308d-2a0f-1e720fd49dcd@mtcc.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] auth-res vs. dmarc X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Dec 2020 09:42:43 -0000 On Tue 29/Dec/2020 22:02:20 +0100 Michael Thomas wrote: > On 12/29/20 12:47 PM, Todd Herr wrote: >>> Unless those values in parens are a MUST requirement, the dmarc=fail is >>> highly misleading. I agree with Michael here. When a (trusted) dmarc=fail is seen downstream, its consumers neither know what policy was specified nor whether it was honored. >> We're going to have to agree to disagree here. I had no hand in writing RFC >> 7601 or its predecessors, but I believe DMARC is covered under "Extension >> Methods" in section 2.7.6 (https://tools.ietf.org/html/rfc7601#section-2.7.6) >> and "Email Authentication Results Names" in section 6.6 By convention, each method specifies the same meanings for the same result names. Yet, methods can have unique codes, for example softfail. If you look at IANA table[*], the meaning of dmarc method is referred to [RFC7489] section 11.2. That section does indeed give the definition of "fail" that Todd has extensively described. However, we are going to obsolete that document, so redefining result names is not out of our reach. [*] https://www.iana.org/assignments/email-auth/email-auth.xhtml#email-auth-result-names >> As for the parenthetical bits, I believe they too are covered in RFC 7601 >> section 2.7.6: For parenthetical info to be machine readable, A-R consumer software has to be dedicated to A-R producer. An blatant standardization shortcoming. > [...] So that's useless for the MUA trying to use auth-res. You would > never display a DMARC FAIL or fail of any kind for p=none. It doesn't > make sense to the user. Likewise, even if we're talking about a > downstream MTA parsing the auth-res, it will be useless to it as well > because it has the same problem not knowing the context of the > "failure". That is especially true for quarantine. As DMARC is often verified by a filter during the SMTP exchange, the filter has to commission the MDA to possibly honor a quarantine request. In order to do that, the filter needs to communicate the results of authentication to the delivery agent. Not using A-R for this task, or resorting to parenthetical info, is preposterous. I propose to add two new result name codes, named after the policy requests: dmarc=quarantine, and dmarc=reject (of course, you only see this if the filter didn't honor the request). Best Ale -- From nobody Wed Dec 30 05:48: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 5C32D3A0A94 for ; Wed, 30 Dec 2020 05:48:25 -0800 (PST) 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 SzUbAQH2-5Bk for ; Wed, 30 Dec 2020 05:48:23 -0800 (PST) Received: from mail-qk1-x733.google.com (mail-qk1-x733.google.com [IPv6:2607:f8b0:4864:20::733]) (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 0D2493A0A73 for ; Wed, 30 Dec 2020 05:48:22 -0800 (PST) Received: by mail-qk1-x733.google.com with SMTP id w79so13890098qkb.5 for ; Wed, 30 Dec 2020 05:48:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=IhKTYB1ZrQu4qBbPWWVcKgeDpjHTKXBKBj28jvJmcTM=; b=TyDoxP1y9Rkr/0c71Fi/7ePszB7DdDAGu+HNj00Y6iVnAGav8rGz1BWxrVQ7nUThZ4 giEPZUH+WExqJxhXrk6jaG3teIW5TLjwTOf2eA8dNZbq3CmCuw3NZnu4Xma8YSIRZ/hj wfZiYKrWOjD8wSuAoVwYEgid/u0dMw1Wl2YoyUPGgWuxUkanMmt3P7vFxsYqm3vjG5Xv 0HheMQRt1Yd/5Q1ZJirYAItrNVNmXMh3oTvDJGTXhp3e+pbHhEIFiiEy3mSrfQK7S5sK ttDVT5IXPz25O2uJOquPe9q4Kifuf5MjUlrHSc0SLrvv7J71A3PZl52/wByfcWW17Xpc CIIw== 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=IhKTYB1ZrQu4qBbPWWVcKgeDpjHTKXBKBj28jvJmcTM=; b=TfHM2puba0ckHsdvra08Pomq0vTLeyJJWKYKNKDdEA2ESImwPO9Y6nTshH9nceZQLC 8APAh56Vz/ls94czP+agLbKvNMfvqqRhe0wTWFQrOV96VZ84QXeVBN0+S1zFSe6oS//R ikTF7WHX2Rack2N2bohhfZsD8tqqM+yusfPuDU9ptJ1J6/Zq4PLQSsw4VyOL/bvck2OU AyIiSesl5ezjvL2nVTA/Kuzu5I/Yg+Hcyls2FMlp11K91+0IB8tU4ibRbjHu0XaiWJ9Z haf1Ss3PzGUekSYzYxYIHuJus3UYMWqe262f/PJDxutV+U4A1UMrpNWszRaBmbaBnC6b ncTg== X-Gm-Message-State: AOAM530yWNkEbPr74xK9uwCvKMig1Q5jgu4QmI137BkF475wLtOqyCFi BZjbYvFX0OKkJRwS8HNiR1HxxwfwdLLMcwRPMx0HhZa1qUDhrg== X-Google-Smtp-Source: ABdhPJzwhr4C6n1bQLEJJHlW/dzlnEhotQ9mMqIdQd59jykU4hea+DXAm+CfPpZpxW4YwuMXsby2xf2sXiuqV45IvAA= X-Received: by 2002:a37:a058:: with SMTP id j85mr55016963qke.387.1609336101669; Wed, 30 Dec 2020 05:48:21 -0800 (PST) MIME-Version: 1.0 References: <9f6782b1-e85b-1a9c-9151-98feff7e18ea@mtcc.com> <140485eb-020f-4406-3f2f-e2c475ea51e5@mtcc.com> <5588dbbe-b876-ed80-c80f-792380e3718f@mtcc.com> <54dd9978-bcd1-6757-ad27-dcef6db6e5f7@mtcc.com> <937f1019-a028-308d-2a0f-1e720fd49dcd@mtcc.com> In-Reply-To: From: Todd Herr Date: Wed, 30 Dec 2020 08:48:05 -0500 Message-ID: To: IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000aa22b405b7aec251" Archived-At: Subject: Re: [dmarc-ietf] auth-res vs. dmarc X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Dec 2020 13:48:25 -0000 --000000000000aa22b405b7aec251 Content-Type: text/plain; charset="UTF-8" On Wed, Dec 30, 2020 at 4:42 AM Alessandro Vesely wrote: > On Tue 29/Dec/2020 22:02:20 +0100 Michael Thomas wrote: > > On 12/29/20 12:47 PM, Todd Herr wrote: > >>> Unless those values in parens are a MUST requirement, the dmarc=fail > is > >>> highly misleading. > > > I agree with Michael here. When a (trusted) dmarc=fail is seen > downstream, its consumers neither know what policy was specified nor > whether it was honored. > That depends on your definition of "downstream", I guess. MDAs and local clients (web and mobile) at the mailbox provider will have the information they need. Third-party MUAs perhaps won't, but MUAs aren't really responsible for message disposition in a way that is relevant to DMARC's primitive disposition choices, except in those cases where they're POP clients that download everything to a local message store, I guess; maybe in that case DMARC policy request and DMARC validation results could be used to make the Inbox v. Spam decision. If the host recording the Auth-Res header is a true intermediary like a mailing list server, there's no disposition information to record that will matter to the downstream; in that case, if the intermediary rejects it, the downstream will never see it, and if it doesn't reject it, then it's not making any disposition decisions. > > >> As for the parenthetical bits, I believe they too are covered in RFC > 7601 > >> section 2.7.6: > > > For parenthetical info to be machine readable, A-R consumer software has > to be dedicated to A-R producer. An blatant standardization shortcoming. > The text of 2.7.6 (RFC 8601) I believe indicates that the parenthetical is just a comment: Authentication method implementers are encouraged to provide adequate information, via message header field comments if necessary, to allow an MUA developer to understand or relay ancillary details of authentication results. For example, if it might be of interest to relay what data were used to perform an evaluation, such information could be relayed as a comment in the header field, such as: Authentication-Results: example.com; foo=pass bar.baz=blob (2 of 3 tests OK) My position is that both the message handling request conveyed by the domain owner in the p= value of their policy record and the message disposition are "ancillary details of authentication results", because while the disposition may be driven by those results, neither impacts the results nor how those results are determined. > > > > [...] So that's useless for the MUA trying to use auth-res. You would > > never display a DMARC FAIL or fail of any kind for p=none. It doesn't > > make sense to the user. Likewise, even if we're talking about a > > downstream MTA parsing the auth-res, it will be useless to it as well > > because it has the same problem not knowing the context of the > > "failure". > > That is especially true for quarantine. As DMARC is often verified by a > filter during the SMTP exchange, the filter has to commission the MDA to > possibly honor a quarantine request. In order to do that, the filter needs > to communicate the results of authentication to the delivery agent. Not > using A-R for this task, or resorting to parenthetical info, is > preposterous. > MDAs have been routing messages to spam folders on the instruction of MTAs long before the Authentication-Results header existed. Many years ago when I worked in email operations, our third-party software supported the concept of the spam-filtering layer inserting an X- header to be read by the MDA to use in inbox/spam folder placement. We're making assumptions in this thread that the A-R header is driving things, but we really have no idea how each mailbox provider does things unless we work there. > > I propose to add two new result name codes, named after the policy > requests: > > dmarc=quarantine, and > > dmarc=reject (of course, you only see this if the filter didn't honor > the request). > > I do not support this, because quarantine, reject, and none are not Authentication Results, but are instead both policy requests and disposition decisions. -- *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. --000000000000aa22b405b7aec251 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Dec 30, 2020 at 4:42 AM Alessandr= o Vesely <vesely@tana.it> wrote= :
On Tue 29/Dec/2020 22:02:20 +0100 Michael Thomas wrote:
> On 12/29/20 12:47 PM, Todd Herr wrote:
>>> Unless those values in parens are a MUST requirement, the dmar= c=3Dfail is
>>> highly misleading.


I agree with Michael here.=C2=A0 When a (trusted) dmarc=3Dfail is seen down= stream, its consumers neither know what policy was specified nor whether it= was honored.

That depends on your defi= nition of "downstream", I guess.=C2=A0

M= DAs and local clients (web and mobile) at the mailbox provider will have th= e information they need.=C2=A0

Third-party MUAs pe= rhaps won't, but MUAs aren't really responsible for message disposi= tion in a way that is relevant to DMARC's=C2=A0primitive disposition ch= oices, except in those cases where they're POP clients that download ev= erything to a local message store, I guess; maybe in that case DMARC policy= request and DMARC validation results could be used to make the Inbox v. Sp= am decision.=C2=A0

If the host recording the Auth-= Res header is a true intermediary like a mailing=C2=A0list server, there= 9;s no disposition information to record that will matter to the downstream= ; in that case, if the intermediary rejects it, the downstream will never s= ee it, and if it doesn't reject it, then it's not making any dispos= ition decisions.



>> As for the parenthetical bits, I believe they too are covered in R= FC 7601
>> section 2.7.6:


For parenthetical info to be machine readable, A-R consumer software has to= be dedicated to A-R producer.=C2=A0 An blatant standardization shortcoming= .

The text of 2.7.6 (RFC 8601) I believ= e indicates that the parenthetical is just a comment:

<= pre class=3D"gmail-newpage" style=3D"font-size:13.3333px;margin-top:0px;mar= gin-bottom:0px;break-before:page;color:rgb(0,0,0)"> Authentication method= implementers are encouraged to provide adequate information, via message header field comments if necessary, to allow an MUA developer to understand or relay ancillary details of authentication results. For example, if it might be of interest to relay what data were used to perform an evaluation, such information could be relayed as a comment in the header field, such as: Authentication-Results: example.com<= /a>; foo=3Dpass bar.baz=3Dblob (2 of 3 tests OK)

My = position is that both the message handling request conveyed by the domain o= wner in the p=3D value of their policy record and the message disposition a= re "ancillary details of authentication results", because while t= he disposition may be driven by those results, neither impacts the results = nor how those results are determined.
=C2=A0


> [...] So that's useless for the MUA trying to use auth-res. You wo= uld
> never display a DMARC FAIL or fail of any kind for p=3Dnone. It doesn&= #39;t
>=C2=A0 make sense to the user. Likewise, even if we're talking abou= t a
> downstream MTA parsing the auth-res, it will be useless to it as well<= br> > because it has the same problem not knowing the context of the
> "failure".

That is especially true for quarantine.=C2=A0 As DMARC is often verified by= a filter during the SMTP exchange, the filter has to commission the MDA to= possibly honor a quarantine request.=C2=A0 In order to do that, the filter= needs to communicate the results of authentication to the delivery agent.= =C2=A0 Not using A-R for this task, or resorting to parenthetical info, is = preposterous.

MDAs have been routing me= ssages to spam folders on the instruction of MTAs long before the Authentic= ation-Results header existed. Many years ago when I worked in email operati= ons, our third-party software supported the concept of the spam-filtering l= ayer inserting an X- header to be read by the MDA to use in inbox/spam fold= er placement. We're making assumptions in this thread that the A-R head= er is driving things, but we really have no idea how each mailbox provider = does things unless we work there.
=C2=A0

I propose to add two new result name codes, named after the policy requests= :

=C2=A0 =C2=A0 dmarc=3Dquarantine, and

=C2=A0 =C2=A0 dmarc=3Dreject (of course, you only see this if the filter di= dn't honor the request).


I do n= ot support this, because quarantine, reject, and none are not Authenticatio= n Results, but are instead both policy requests and disposition decisions.= =C2=A0

--

To= dd Herr | Sr. Technical Program Manager
p: 703.220.4153


This email and all data transmitte= d with it contains confidential and/or proprietary information intended sol= ely for the use of individual(s) authorized to receive it. If you are not a= n intended and authorized recipient you are hereby notified of any use, dis= closure, copying or distribution of the information included in this transm= ission is prohibited and may be unlawful. Please immediately notify the sen= der by replying to this email and then delete it from your system.

--000000000000aa22b405b7aec251-- From nobody Wed Dec 30 05:55: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 9267F3A0AD6 for ; Wed, 30 Dec 2020 05:55:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, 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=mtcc.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 yDCvSQLjYYBy for ; Wed, 30 Dec 2020 05:55:45 -0800 (PST) Received: from mail-pf1-x435.google.com (mail-pf1-x435.google.com [IPv6:2607:f8b0:4864:20::435]) (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 08DE63A0AD3 for ; Wed, 30 Dec 2020 05:55:44 -0800 (PST) Received: by mail-pf1-x435.google.com with SMTP id c12so9722884pfo.10 for ; Wed, 30 Dec 2020 05:55:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mtcc.com; s=fluffulence; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=xITvwwRWEX+neCpAdYcPjMxOUZ4T4yJn5/xic3xWNXM=; b=J8cs+fLKUnLd2jAnGUZh8rAcB+htOqEQGWLCwvVwxk68UGmXDXGBHD7+giy+DvMj8a EdM66haUdS/NFGkHrRACjhor+bvJGWJo/gTnpXndwAzsPe5/iByMrDBqTdrd9GL/aWmT K+yCHiWmbTYyLrYCKQSuW+ueb8M8/SvdlMVqSCNwbLSndv45TZgR1yr/aLxbG0Ok+GSE OW2w55cmZ2yPy9AI5W39/ztiwbt8/e0+72d2gEXbK8zToaAnwof2fTVwA/onQYTa5Tom yR/sYUGkg1mKkOFNpb35Z3pPaZDsWuNTcdjJ6jG796RO6DoGxjm2ejKvbA6+yU9oVus+ qr1Q== 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=xITvwwRWEX+neCpAdYcPjMxOUZ4T4yJn5/xic3xWNXM=; b=scHDiXcH7J0A14iFSb/7QdSTFE6m46IEpjKXVlyKUHWEqlDtkDTO0IFMsU5eQX0RMt QyVYhRfwHkMrxcSCI2IfO+XSQK/SigC/eEWdJG2Lae2AxdN3Xogxn4Z+5sNv/s3iZw/L kILnZi4ccJVwUyjnKgKDgeUPjmb2awAQokjjV5E3Q49uU/vqeMIh4i5Hwf7jwDulbDb4 yLSd37FBMVaaEvzcdpiO9FLN+ffLTEgMaix+EXB5TwvVjWDEeqzhpsyfBfTta1QeAC3M C+TVUvuxQ3cupl0zguF7oXJQ1cjIQvZvLT0Zsh21I1AJium+Narg423EATsfBLOo+zV2 i3Mg== X-Gm-Message-State: AOAM5305iY7MRrqlJNNUpvJ4IWQB1zrStWQAdXpclR2+vcdub2wRtbrz sLDRoNngfxmaBeRuHrnISfaOD1AKutp0KA== X-Google-Smtp-Source: ABdhPJxw2ggqh8KxNjVr+FIR+Qp7uSyFu7Q+CMBQQ/SKY2/IkcRDwUADravDRT//NYIYtBTgrS/yjw== X-Received: by 2002:a62:8205:0:b029:19e:717c:d647 with SMTP id w5-20020a6282050000b029019e717cd647mr48586306pfd.50.1609336543950; Wed, 30 Dec 2020 05:55:43 -0800 (PST) Received: from mike-mac.lan (107-182-45-95.volcanocom.com. [107.182.45.95]) by smtp.gmail.com with ESMTPSA id d20sm8621911pjz.3.2020.12.30.05.55.42 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 30 Dec 2020 05:55:43 -0800 (PST) To: dmarc@ietf.org References: <9f6782b1-e85b-1a9c-9151-98feff7e18ea@mtcc.com> <140485eb-020f-4406-3f2f-e2c475ea51e5@mtcc.com> <5588dbbe-b876-ed80-c80f-792380e3718f@mtcc.com> <54dd9978-bcd1-6757-ad27-dcef6db6e5f7@mtcc.com> <937f1019-a028-308d-2a0f-1e720fd49dcd@mtcc.com> From: Michael Thomas Message-ID: <9c5f18c2-c5f6-4f66-a185-f684949738b5@mtcc.com> Date: Wed, 30 Dec 2020 05:55:41 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------C872739695E3A14EF3E33EAD" Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] auth-res vs. dmarc X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Dec 2020 13:55:47 -0000 This is a multi-part message in MIME format. --------------C872739695E3A14EF3E33EAD Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 12/30/20 5:48 AM, Todd Herr wrote: > On Wed, Dec 30, 2020 at 4:42 AM Alessandro Vesely > wrote: > > On Tue 29/Dec/2020 22:02:20 +0100 Michael Thomas wrote: > > On 12/29/20 12:47 PM, Todd Herr wrote: > >>> Unless those values in parens are a MUST requirement, the > dmarc=fail is > >>> highly misleading. > > > I agree with Michael here.  When a (trusted) dmarc=fail is seen > downstream, its consumers neither know what policy was specified > nor whether it was honored. > > > That depends on your definition of "downstream", I guess. > > MDAs and local clients (web and mobile) at the mailbox provider will > have the information they need. No they don't. I keep saying this, but you guys keep dismissing me. Painting up "fail" for p=none is absolutely the wrong thing to do. It is not what the user expects to see for a piece of mail that is perfectly acceptable to the originating domain. This is an error or omission, full stop. Mike --------------C872739695E3A14EF3E33EAD Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit


On 12/30/20 5:48 AM, Todd Herr wrote:
On Wed, Dec 30, 2020 at 4:42 AM Alessandro Vesely <vesely@tana.it> wrote:
On Tue 29/Dec/2020 22:02:20 +0100 Michael Thomas wrote:
> On 12/29/20 12:47 PM, Todd Herr wrote:
>>> Unless those values in parens are a MUST requirement, the dmarc=fail is
>>> highly misleading.


I agree with Michael here.  When a (trusted) dmarc=fail is seen downstream, its consumers neither know what policy was specified nor whether it was honored.

That depends on your definition of "downstream", I guess. 

MDAs and local clients (web and mobile) at the mailbox provider will have the information they need.

No they don't. I keep saying this, but you guys keep dismissing me. Painting up "fail" for p=none is absolutely the wrong thing to do. It is not what the user expects to see for a piece of mail that is perfectly acceptable to the originating domain. This is an error or omission, full stop.

Mike

--------------C872739695E3A14EF3E33EAD-- From nobody Wed Dec 30 06:01: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 991093A0AD6 for ; Wed, 30 Dec 2020 06:01:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, 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=mtcc.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 5g5LOg7oSK5X for ; Wed, 30 Dec 2020 06:01:37 -0800 (PST) Received: from mail-pl1-x632.google.com (mail-pl1-x632.google.com [IPv6:2607:f8b0:4864:20::632]) (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 7FB863A0ACC for ; Wed, 30 Dec 2020 06:01:37 -0800 (PST) Received: by mail-pl1-x632.google.com with SMTP id t6so8720706plq.1 for ; Wed, 30 Dec 2020 06:01:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mtcc.com; s=fluffulence; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=TfWjyD9x/aPrsiy7z1n6CjyJtj2MNtE0y1XYvkyFVqA=; b=kZGCFPi4yyD5olWKsOvOMnLWIuU3dC6WTeN/EDmkzNrmQ+r2tjrZ2OQVemw2BG02iU bqEfkeXdZedA9UOjpjVYB2eIlUEc+ktGjVKpQj66s8nKEJ6MWKRMfdIeOCGic0yc7Ie5 QQ/KvYVpFBjzb5+qJb6THSErOYHAOnPTGQ81F69P7j/G47WTHFXYkdrWpXEK3/JPLvvX qIYjcO+nJbEVo0g1GOGVQVwG8/lhMy6NiI2jqJ7MMaGH4SCjE0v7FPRf1yDUYuwCxZRA s5XJ9nmp7mDUZE/Msl6pMiH04M07/1AVQWuBavZqbW7CbIUAUYbZhky6wTdqM9vG4XRW 7Eow== 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=TfWjyD9x/aPrsiy7z1n6CjyJtj2MNtE0y1XYvkyFVqA=; b=NI/Sc2zBEXqN0nKyA4WDX6J0br/HruB60LWSEJL8CpBQmpxRaG1YbrGMOJ2IVVV4AY 3ujro2Ara1PQ3s7BnLtDn/n8z/9MCz//5a/+6nauq2/3UBHBbgunm8cJFv0uub1FvTNS axlQbhEu7vms1KbcAgIG76hl2Bl6aWmgukoZ6omcdpeBQV3dDeTvfNsRUslpIj++AOFg /fe92abYkeW9P6Y/pKzkeJ3UCuIR1mnA30fv9ePSyIh88u7Sjj8I71lTLh12XeDqLnAk oArGJPr3lz2PS/u0tjGN+RJ2LHJAuy4PrhZi1eLP8Pkrp/Sivy9UDxxzI48IQz0nzpUs l4vg== X-Gm-Message-State: AOAM531NR35G8N65qca8FoiX04f+/AgqLWjfnY0/xSS4SsZdIS8dyM1H bSE4X/uEcBVfUyDJjbTQWoDNA3LdBq0uxw== X-Google-Smtp-Source: ABdhPJwSSM8RFDJgxkcpwGtwgNGkfXeU+15bctxGVjHMYQZtEIWJaLEqq/I4elNIJVknPz1QoBPTzw== X-Received: by 2002:a17:902:bcc6:b029:db:e257:9050 with SMTP id o6-20020a170902bcc6b02900dbe2579050mr31520380pls.22.1609336896313; Wed, 30 Dec 2020 06:01:36 -0800 (PST) Received: from mike-mac.lan (107-182-45-95.volcanocom.com. [107.182.45.95]) by smtp.gmail.com with ESMTPSA id j8sm7131749pji.1.2020.12.30.06.01.34 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 30 Dec 2020 06:01:35 -0800 (PST) To: dmarc@ietf.org References: <9f6782b1-e85b-1a9c-9151-98feff7e18ea@mtcc.com> <140485eb-020f-4406-3f2f-e2c475ea51e5@mtcc.com> <5588dbbe-b876-ed80-c80f-792380e3718f@mtcc.com> <54dd9978-bcd1-6757-ad27-dcef6db6e5f7@mtcc.com> <937f1019-a028-308d-2a0f-1e720fd49dcd@mtcc.com> From: Michael Thomas Message-ID: <72e20c17-e991-e82a-9120-a27097e3ac58@mtcc.com> Date: Wed, 30 Dec 2020 06:01:34 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------827133265C3AE28F4F96EA5F" Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] auth-res vs. dmarc X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Dec 2020 14:01:39 -0000 This is a multi-part message in MIME format. --------------827133265C3AE28F4F96EA5F Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 12/30/20 5:48 AM, Todd Herr wrote: > > I propose to add two new result name codes, named after the policy > requests: > >     dmarc=quarantine, and > >     dmarc=reject (of course, you only see this if the filter > didn't honor the request). > > > I do not support this, because quarantine, reject, and none are not > Authentication Results, but are instead both policy requests and > disposition decisions. > Then we should remove DMARC from auth-res altogether because it is not an authentication mechanism. Either we fully support DMARC in auth-res or remove it. This half-assed state of unlessness serves nobody. Mike --------------827133265C3AE28F4F96EA5F Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit


On 12/30/20 5:48 AM, Todd Herr wrote:

I propose to add two new result name codes, named after the policy requests:

    dmarc=quarantine, and

    dmarc=reject (of course, you only see this if the filter didn't honor the request).


I do not support this, because quarantine, reject, and none are not Authentication Results, but are instead both policy requests and disposition decisions. 

Then we should remove DMARC from auth-res altogether because it is not an authentication mechanism. Either we fully support DMARC in auth-res or remove it. This half-assed state of unlessness serves nobody.

Mike

--------------827133265C3AE28F4F96EA5F-- From nobody Wed Dec 30 06:48: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 1B4143A0BDF for ; Wed, 30 Dec 2020 06:48:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, 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=mtcc.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 9zh35ijJa8U0 for ; Wed, 30 Dec 2020 06:48:17 -0800 (PST) Received: from mail-pl1-x631.google.com (mail-pl1-x631.google.com [IPv6:2607:f8b0:4864:20::631]) (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 0BCD03A0BDE for ; Wed, 30 Dec 2020 06:48:16 -0800 (PST) Received: by mail-pl1-x631.google.com with SMTP id s15so8748334plr.9 for ; Wed, 30 Dec 2020 06:48:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mtcc.com; s=fluffulence; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=FYi1iSSPLZtAae/2xrOARJqtpT1dPi3lyyKT57hdYTY=; b=YCzQaxjfqVy6po/WdYMX7s+ngm5ZNyjs8528FDKJJTDKvLiDsA3dbs5WPq+EMO7ex8 3JaZ9ViLStCcrZePx9809/OrLZtXEr02RTMCrZzRgOYaM34wN+kLVKrffoJHfhU50VPt vDP5MJhMU+iC+rVBKGCBwRcyk2LwHIH+u8h1gylCX/lWox3iA/6YMC7T0dycRt1Q9KdP 26gQm3Cllcakjsiwjj6g5FysU9uknQtaEB3tPsqxfEL7YTRWl0+7jHr6KlS72LQHYXd+ cxwbSc8Y9G7xKzO2cVa1uJzQI2m7ZxoVYi9ke465Ff0uXBPkXfc4mb8NlKMrm85a/IUR dDeg== 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=FYi1iSSPLZtAae/2xrOARJqtpT1dPi3lyyKT57hdYTY=; b=DRdBaZVQwyXRet0rb9SnE5tJ6veisDa3hntq2JVhGVRM5JUpUHp27M6DYYxdAzM8iP VEaaXjgVEtfV5QGzuASKG8ftVJFTZDAtuoZ6a0ejzFSmy3hp1udP5X/s/BriPcIH+JWR 3p1wAnU1LxZoJJuQZRQJfvH8pmQ3QcFR45Ll0gvHT87XRJh2nWFAT8vLlLRH8Er1ZhqU s3zGSW0N4AGMqU3YckIs4SRpvVKWCB/DOA9aMKAX81C3dtRtd6LLkKWHssvGvx+NvW9K IXJduLavVbv+zZvdGYmquWZjsEjxeRRIQbjl2Ni+ciJM8QXDUR6+2y9hD88eSVKxIy33 FPqw== X-Gm-Message-State: AOAM5320HnebfV/UTqlWpamHVmOI7UOeF5oYyKwyYWm8NlYPY/DtZPkI nKgav7IBLPscwM6VOMB+1zKm9r7WIEjNvw== X-Google-Smtp-Source: ABdhPJwwdoojexG0D2DI4FNAWVGqwx48ctS+FkNH9fM059M7ubs5dyNCIXd5R1EQN9dAxQT1/OUHEw== X-Received: by 2002:a17:902:6b0a:b029:dc:31af:8dc3 with SMTP id o10-20020a1709026b0ab02900dc31af8dc3mr31171735plk.41.1609339695989; Wed, 30 Dec 2020 06:48:15 -0800 (PST) Received: from mike-mac.lan (107-182-45-95.volcanocom.com. [107.182.45.95]) by smtp.gmail.com with ESMTPSA id a10sm41836724pfi.168.2020.12.30.06.48.14 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 30 Dec 2020 06:48:15 -0800 (PST) To: dmarc@ietf.org References: <9f6782b1-e85b-1a9c-9151-98feff7e18ea@mtcc.com> <140485eb-020f-4406-3f2f-e2c475ea51e5@mtcc.com> <5588dbbe-b876-ed80-c80f-792380e3718f@mtcc.com> <54dd9978-bcd1-6757-ad27-dcef6db6e5f7@mtcc.com> <937f1019-a028-308d-2a0f-1e720fd49dcd@mtcc.com> From: Michael Thomas Message-ID: <190eb548-fd21-559a-1441-faabbfcefdc0@mtcc.com> Date: Wed, 30 Dec 2020 06:48:14 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------804C7906588894D161479327" Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] auth-res vs. dmarc X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Dec 2020 14:48:18 -0000 This is a multi-part message in MIME format. --------------804C7906588894D161479327 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 12/30/20 5:48 AM, Todd Herr wrote: > > Third-party MUAs perhaps won't, but MUAs aren't really responsible for > message disposition in a way that is relevant to DMARC's primitive > disposition choices, except in those cases where they're POP clients > that download everything to a local message store, I guess; maybe in > that case DMARC policy request and DMARC validation results could be > used to make the Inbox v. Spam decision. > This is a failure of imagination. If spam filters are too worried about false positives to take action on p=reject and p=quarantine, that doesn't mean a human can't. Imagine three colors, green, orange and red. If I see red, I am immediately suspicious of it and treat it as suspect when evaluating the context and semantics in the message -- something that spam filters do not do. Same to a lesser degree orange. If auth-res provided me the proper information, I could do that today. I cannot because it does not. As it stands today, auth-res is useless for DMARC. Mike --------------804C7906588894D161479327 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit


On 12/30/20 5:48 AM, Todd Herr wrote:

Third-party MUAs perhaps won't, but MUAs aren't really responsible for message disposition in a way that is relevant to DMARC's primitive disposition choices, except in those cases where they're POP clients that download everything to a local message store, I guess; maybe in that case DMARC policy request and DMARC validation results could be used to make the Inbox v. Spam decision. 

This is a failure of imagination. If spam filters are too worried about false positives to take action on p=reject and p=quarantine, that doesn't mean a human can't. Imagine three colors, green, orange and red. If I see red, I am immediately suspicious of it and treat it as suspect when evaluating the context and semantics in the message -- something that spam filters do not do. Same to a lesser degree orange. If auth-res provided me the proper information, I could do that today. I cannot because it does not. As it stands today, auth-res is useless for DMARC.

Mike

--------------804C7906588894D161479327-- From nobody Wed Dec 30 07:06: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 B146D3A00C4 for ; Wed, 30 Dec 2020 07:06:04 -0800 (PST) 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 uf1HHL0DLhap for ; Wed, 30 Dec 2020 07:06:02 -0800 (PST) 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 9EC183A0045 for ; Wed, 30 Dec 2020 07:06:02 -0800 (PST) Received: by mail-qv1-xf31.google.com with SMTP id h16so7782481qvu.8 for ; Wed, 30 Dec 2020 07:06:02 -0800 (PST) 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=QqH0s4YGqqYtnsEOTXjNE1YfOKDjM8YleT417+Li6Jc=; b=cfQ/9Qc9pTIVUoQTythYQrNwu5ipw64J3VXHWRAni+bdMaOoWiIlnHwvINRyv0p9OI /JxDlcT+ewm1JlNN63GS2OS+D9rsEzMjaMUfB5UlU7Wa8VmOAfHbFV/Mg4J2W9HefdSU +rDHxNWqYNgNKut8XZdG5XAWEyk84ZutB0QmJSzjPNS9dUtfQeFO4kJV0psTGL2U/Xnk 8Cj4PgWUEEUjDk3CwdjaFZsNJBf6cwBxMRp03xoCUE6hmHIk+2JgUl9R0cRE9nDVrtIw NagWDWJT+e8DhJPlUkuC0eyxou1MA73P67QAu4pCLjk1v9xQdc+tPnRbGZBIVb0MxZBT E86Q== 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=QqH0s4YGqqYtnsEOTXjNE1YfOKDjM8YleT417+Li6Jc=; b=Ged9zIjsFsJy6aNIrPa0cPA9pi+65Bb5JnJB1gBI1t/Ve2nDEr7WGVYmYlAENdneZn lHsUHsUqTJIrsP9U1KlszbJVzxw2F94TS9BDKAHeU6Msk6x6Mw1MrFytd4qRHLYvZxRi P2fu15lHtewN1GcOurD5CfD5Pvrib3biiJPJXdiskS4LC8atp6ap9ivGvK+tQcN8lgZ/ W4tLrTKLpGdKhufGomeQdhz2TTqWhrCrJR0p1SD9ZWlas8IfYjrBmLsGC9gWHGOC+c+6 52lI5jsmQAZ9JX8tRosYjQ5zpdlDyaUaSoplOv9UsuttH8QMjnTZ7P0lXrN0LFIvz+6q ZEEw== X-Gm-Message-State: AOAM530uAI7wbJn2R5TIYX2xbYE8PUbeYExjE6SKxvWGEURQyjMg0+Qd RYTXMPm5m+aSZX7mwUaNszzR8LyCxMSOh5cgkgoo3sOz X-Google-Smtp-Source: ABdhPJy0m4oaT67qhmX76NQz7JU1irDX9GhWOCqO3C+GAAbiNrtKUD+t/3lNlE+ibkY4ad3r5u05SmOvT0hmPbGRzD8= X-Received: by 2002:ad4:5762:: with SMTP id r2mr57482343qvx.45.1609340761497; Wed, 30 Dec 2020 07:06:01 -0800 (PST) MIME-Version: 1.0 References: <9f6782b1-e85b-1a9c-9151-98feff7e18ea@mtcc.com> <140485eb-020f-4406-3f2f-e2c475ea51e5@mtcc.com> <5588dbbe-b876-ed80-c80f-792380e3718f@mtcc.com> <54dd9978-bcd1-6757-ad27-dcef6db6e5f7@mtcc.com> <937f1019-a028-308d-2a0f-1e720fd49dcd@mtcc.com> In-Reply-To: From: Dotzero Date: Wed, 30 Dec 2020 10:05:50 -0500 Message-ID: To: Todd Herr Cc: IETF DMARC WG Content-Type: multipart/alternative; boundary="00000000000069655705b7afd8dc" Archived-At: Subject: Re: [dmarc-ietf] auth-res vs. dmarc X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Dec 2020 15:06:05 -0000 --00000000000069655705b7afd8dc Content-Type: text/plain; charset="UTF-8" Absolutely agree with Todd's analysis and comments. +1 Michael Hammer On Wed, Dec 30, 2020 at 8:48 AM Todd Herr wrote: > On Wed, Dec 30, 2020 at 4:42 AM Alessandro Vesely wrote: > >> On Tue 29/Dec/2020 22:02:20 +0100 Michael Thomas wrote: >> > On 12/29/20 12:47 PM, Todd Herr wrote: >> >>> Unless those values in parens are a MUST requirement, the dmarc=fail >> is >> >>> highly misleading. >> >> >> I agree with Michael here. When a (trusted) dmarc=fail is seen >> downstream, its consumers neither know what policy was specified nor >> whether it was honored. >> > > That depends on your definition of "downstream", I guess. > > MDAs and local clients (web and mobile) at the mailbox provider will have > the information they need. > > Third-party MUAs perhaps won't, but MUAs aren't really responsible for > message disposition in a way that is relevant to DMARC's primitive > disposition choices, except in those cases where they're POP clients that > download everything to a local message store, I guess; maybe in that case > DMARC policy request and DMARC validation results could be used to make the > Inbox v. Spam decision. > > If the host recording the Auth-Res header is a true intermediary like a > mailing list server, there's no disposition information to record that will > matter to the downstream; in that case, if the intermediary rejects it, the > downstream will never see it, and if it doesn't reject it, then it's not > making any disposition decisions. > > >> >> >> As for the parenthetical bits, I believe they too are covered in RFC >> 7601 >> >> section 2.7.6: >> >> >> For parenthetical info to be machine readable, A-R consumer software has >> to be dedicated to A-R producer. An blatant standardization shortcoming. >> > > The text of 2.7.6 (RFC 8601) I believe indicates that the parenthetical is > just a comment: > > Authentication method implementers are encouraged to provide adequate > information, via message header field comments if necessary, to allow > an MUA developer to understand or relay ancillary details of > authentication results. For example, if it might be of interest to > relay what data were used to perform an evaluation, such information > could be relayed as a comment in the header field, such as: > > Authentication-Results: example.com; > foo=pass bar.baz=blob (2 of 3 tests OK) > > > > My position is that both the message handling request conveyed by the > domain owner in the p= value of their policy record and the message > disposition are "ancillary details of authentication results", because > while the disposition may be driven by those results, neither impacts the > results nor how those results are determined. > > >> >> >> > [...] So that's useless for the MUA trying to use auth-res. You would >> > never display a DMARC FAIL or fail of any kind for p=none. It doesn't >> > make sense to the user. Likewise, even if we're talking about a >> > downstream MTA parsing the auth-res, it will be useless to it as well >> > because it has the same problem not knowing the context of the >> > "failure". >> >> That is especially true for quarantine. As DMARC is often verified by a >> filter during the SMTP exchange, the filter has to commission the MDA to >> possibly honor a quarantine request. In order to do that, the filter needs >> to communicate the results of authentication to the delivery agent. Not >> using A-R for this task, or resorting to parenthetical info, is >> preposterous. >> > > MDAs have been routing messages to spam folders on the instruction of MTAs > long before the Authentication-Results header existed. Many years ago when > I worked in email operations, our third-party software supported the > concept of the spam-filtering layer inserting an X- header to be read by > the MDA to use in inbox/spam folder placement. We're making assumptions in > this thread that the A-R header is driving things, but we really have no > idea how each mailbox provider does things unless we work there. > > >> >> I propose to add two new result name codes, named after the policy >> requests: >> >> dmarc=quarantine, and >> >> dmarc=reject (of course, you only see this if the filter didn't honor >> the request). >> >> > I do not support this, because quarantine, reject, and none are not > Authentication Results, but are instead both policy requests and > disposition decisions. > > -- > > *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. > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > --00000000000069655705b7afd8dc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Absolutely agree with Todd's analysis and comment= s. +1

Michael Hammer

On Wed, Dec 30, 2020= at 8:48 AM Todd Herr <todd.herr=3D40valimail.com@dmarc.ietf.org> wrote:
= On Wed, Dec 30, 2020 at 4:42 AM Alessandro Vesely <vesely@tana.it> wrote:
On = Tue 29/Dec/2020 22:02:20 +0100 Michael Thomas wrote:
> On 12/29/20 12:47 PM, Todd Herr wrote:
>>> Unless those values in parens are a MUST requirement, the dmar= c=3Dfail is
>>> highly misleading.


I agree with Michael here.=C2=A0 When a (trusted) dmarc=3Dfail is seen down= stream, its consumers neither know what policy was specified nor whether it= was honored.

That depends on your defi= nition of "downstream", I guess.=C2=A0

M= DAs and local clients (web and mobile) at the mailbox provider will have th= e information they need.=C2=A0

Third-party MUAs pe= rhaps won't, but MUAs aren't really responsible for message disposi= tion in a way that is relevant to DMARC's=C2=A0primitive disposition ch= oices, except in those cases where they're POP clients that download ev= erything to a local message store, I guess; maybe in that case DMARC policy= request and DMARC validation results could be used to make the Inbox v. Sp= am decision.=C2=A0

If the host recording the Auth-= Res header is a true intermediary like a mailing=C2=A0list server, there= 9;s no disposition information to record that will matter to the downstream= ; in that case, if the intermediary rejects it, the downstream will never s= ee it, and if it doesn't reject it, then it's not making any dispos= ition decisions.



>> As for the parenthetical bits, I believe they too are covered in R= FC 7601
>> section 2.7.6:


For parenthetical info to be machine readable, A-R consumer software has to= be dedicated to A-R producer.=C2=A0 An blatant standardization shortcoming= .

The text of 2.7.6 (RFC 8601) I believ= e indicates that the parenthetical is just a comment:

<= pre style=3D"font-size:13.3333px;margin-top:0px;margin-bottom:0px;break-bef= ore:page;color:rgb(0,0,0)"> Authentication method implementers are encour= aged to provide adequate information, via message header field comments if necessary, to allow an MUA developer to understand or relay ancillary details of authentication results. For example, if it might be of interest to relay what data were used to perform an evaluation, such information could be relayed as a comment in the header field, such as: Authentication-Results: example.com; foo=3Dpass bar.baz=3Dblob (2 of 3 tests OK)

My position is that both the message handling= request conveyed by the domain owner in the p=3D value of their policy rec= ord and the message disposition are "ancillary details of authenticati= on results", because while the disposition may be driven by those resu= lts, neither impacts the results nor how those results are determined.
=C2=A0


> [...] So that's useless for the MUA trying to use auth-res. You wo= uld
> never display a DMARC FAIL or fail of any kind for p=3Dnone. It doesn&= #39;t
>=C2=A0 make sense to the user. Likewise, even if we're talking abou= t a
> downstream MTA parsing the auth-res, it will be useless to it as well<= br> > because it has the same problem not knowing the context of the
> "failure".

That is especially true for quarantine.=C2=A0 As DMARC is often verified by= a filter during the SMTP exchange, the filter has to commission the MDA to= possibly honor a quarantine request.=C2=A0 In order to do that, the filter= needs to communicate the results of authentication to the delivery agent.= =C2=A0 Not using A-R for this task, or resorting to parenthetical info, is = preposterous.

MDAs have been routing me= ssages to spam folders on the instruction of MTAs long before the Authentic= ation-Results header existed. Many years ago when I worked in email operati= ons, our third-party software supported the concept of the spam-filtering l= ayer inserting an X- header to be read by the MDA to use in inbox/spam fold= er placement. We're making assumptions in this thread that the A-R head= er is driving things, but we really have no idea how each mailbox provider = does things unless we work there.
=C2=A0

I propose to add two new result name codes, named after the policy requests= :

=C2=A0 =C2=A0 dmarc=3Dquarantine, and

=C2=A0 =C2=A0 dmarc=3Dreject (of course, you only see this if the filter di= dn't honor the request).


I do n= ot support this, because quarantine, reject, and none are not Authenticatio= n Results, but are instead both policy requests and disposition decisions.= =C2=A0

--

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 auth= orized recipient you are hereby notified of any use, disclosure, copying or= distribution of the information included in this transmission is prohibite= d and may be unlawful. Please immediately notify the sender by replying to = this email and then delete it from your system.

_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
--00000000000069655705b7afd8dc-- From nobody Wed Dec 30 07:07: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 7CF7F3A005C for ; Wed, 30 Dec 2020 07:06:59 -0800 (PST) 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 yMqcHMMVtkW4 for ; Wed, 30 Dec 2020 07:06:57 -0800 (PST) Received: from mail.wordtothewise.com (mail.wordtothewise.com [104.225.223.158]) by ietfa.amsl.com (Postfix) with ESMTP id BEFF73A0045 for ; Wed, 30 Dec 2020 07:06:57 -0800 (PST) Received: from [192.168.0.227] (unknown [37.228.231.27]) by mail.wordtothewise.com (Postfix) with ESMTPSA id 1FB039F149 for ; Wed, 30 Dec 2020 07:06:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=wordtothewise.com; s=aardvark; t=1609340817; bh=G6p0rwMF/yPe3YR5jWyssoMZQCCReIq7e5s6Z6eXFw4=; h=From:Subject:Date:References:To:In-Reply-To:From; b=Zsx/8eIeTKVvhRWASbAglUOQExCFQ8p7D7cE7Hxwr/nIyfmrhuGVK0EdESFZOUIyG N2ayxyygMgikYJI3jqprQvt41pRsYOuh5SLGRA401Tda0JTqEpY6CJFANIkkizdDlY b4aZqW9NtbK3vnF2x4eaSrsTafHqSFLmlLtfuNbA= From: Laura Atkins Content-Type: multipart/alternative; boundary="Apple-Mail=_5C38446B-5E9F-4BA4-92D6-FC8299DE4550" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Date: Wed, 30 Dec 2020 15:06:53 +0000 References: <9f6782b1-e85b-1a9c-9151-98feff7e18ea@mtcc.com> <140485eb-020f-4406-3f2f-e2c475ea51e5@mtcc.com> <5588dbbe-b876-ed80-c80f-792380e3718f@mtcc.com> <54dd9978-bcd1-6757-ad27-dcef6db6e5f7@mtcc.com> <937f1019-a028-308d-2a0f-1e720fd49dcd@mtcc.com> To: IETF DMARC WG In-Reply-To: Message-Id: <53A477E1-3FE1-4D84-A930-BBC6AD006C05@wordtothewise.com> X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [dmarc-ietf] auth-res vs. dmarc X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Dec 2020 15:07:00 -0000 --Apple-Mail=_5C38446B-5E9F-4BA4-92D6-FC8299DE4550 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On 30 Dec 2020, at 09:42, Alessandro Vesely wrote: >=20 > On Tue 29/Dec/2020 22:02:20 +0100 Michael Thomas wrote: >> On 12/29/20 12:47 PM, Todd Herr wrote: >>>> Unless those values in parens are a MUST requirement, the = dmarc=3Dfail is highly misleading. >=20 >=20 > I agree with Michael here. When a (trusted) dmarc=3Dfail is seen = downstream, its consumers neither know what policy was specified nor = whether it was honored. The auth-res result posted as an example of DMARC failing earlier in = this thread:=20 Authentication-Results: mx.google.com ; dkim=3Dpass header.i=3D@ietf.org = header.s=3Dietf1 header.b=3DaayvF8Pg; dkim=3Dpass header.i=3D@ietf.org = header.s=3Dietf1 header.b=3D"PwU4/yuQ"; dkim=3Dneutral (body hash did not verify) header.i=3D@mrochek.com = header.s=3D201712 header.b=3DPRr8Q7Zv; spf=3Dpass (google.com : domain of = dmarc-bounces@ietf.org designates = 4.31.198.44 as permitted sender) smtp.mailfrom=3Ddmarc-bounces@ietf.org = ; dmarc=3Dfail (p=3DNONE sp=3DNONE dis=3DNONE) = header.from=3Dmrochek.com The policy statement is right there: p=3DNONE.=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=_5C38446B-5E9F-4BA4-92D6-FC8299DE4550 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

On 30 Dec 2020, at 09:42, Alessandro Vesely <vesely@tana.it> = wrote:

On Tue 29/Dec/2020 22:02:20 +0100 Michael Thomas wrote:
On 12/29/20 12:47 PM, = Todd Herr wrote:
Unless those values in = parens are a MUST requirement, the dmarc=3Dfail is highly misleading.


I agree with Michael here.  When a (trusted) dmarc=3Dfail = is seen downstream, its consumers neither know what policy was specified = nor whether it was honored.

The = auth-res result posted as an example of DMARC failing earlier in this = thread: 
Authentication-Results: mx.google.com;
       dkim=3Dpass header.i=3D@ietf.org =
header.s=3Dietf1 header.b=3DaayvF8Pg;
       dkim=3Dpass header.i=3D@ietf.org =
header.s=3Dietf1 header.b=3D"PwU4/yuQ";
       dkim=3Dneutral (body hash did not verify) header.i=3D@mrochek.com =
header.s=3D201712 header.b=3DPRr8Q7Zv;
       spf=3Dpass (google.com: domain of dmarc-bounces@ietf.org =
designates 4.31.198.44 as permitted sender) smtp.mailfrom=3Ddma=
rc-bounces@ietf.org;
       dmarc=3Dfail (p=3DNONE sp=3DNONE dis=3DNONE) header.from=3Dmrochek.com
The policy statement is right there: p=3DNONE. 

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=_5C38446B-5E9F-4BA4-92D6-FC8299DE4550-- From nobody Wed Dec 30 07:17: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 32C703A0140 for ; Wed, 30 Dec 2020 07:17:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, 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=mtcc.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 BrKPnUGF16Eb for ; Wed, 30 Dec 2020 07:17:25 -0800 (PST) Received: from mail-pj1-x1034.google.com (mail-pj1-x1034.google.com [IPv6:2607:f8b0:4864:20::1034]) (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 C54463A011B for ; Wed, 30 Dec 2020 07:17:25 -0800 (PST) Received: by mail-pj1-x1034.google.com with SMTP id hk16so3835182pjb.4 for ; Wed, 30 Dec 2020 07:17:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mtcc.com; s=fluffulence; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=6G1t2VKogUJyBWvf9Tbx+l2wVFP4oNfbV/VtmI5O6rs=; b=hzwyF247BZECWD5u1NYvZ7j8jDIxYqUSRyMHDdqM8gsFwkuliWl7Foq/w2J76gslm6 U0G549WNJWG6QcqCuklgefqXEr/dXiqpjclrSjLkJa/dd/iLKKkZXHJMxrKZdVEJj3S6 OUX5bo2LYpq2bUnN0bS6JPtStl/4/2xQ3vVQCMcOxZauX4yDwiWC0ksHnx4pwP3INqS4 /tdU79gOzxJp14qpMQSy1JbTMKV4F53Upib1LGV1JlrlcmxfcWKHHpq/RmyZPA4WIcq4 x8lHHUUe59I18LmFfQMejUZ1k2EDDyPEbUahyWb+3mkcizMxdlIYKi+LbnNr0hfXEgFk ZYOw== 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=6G1t2VKogUJyBWvf9Tbx+l2wVFP4oNfbV/VtmI5O6rs=; b=RvjgWkttkwI8XijbAyytPEjAiAFcu/z73Rp++BxZIfPFCxNVYU5Xj9SBhucFOVNQ/K UHcgRE3MhkEDwv+MySDFdSNDzM23wS6ld4HKFyIFzWNTx+F5rt3bFZ8hupRYIynP0Rog Mm0IbefWrxclOk8/tzSD1HiUrEzIOhk1a1XHQI9k3D7rUnlTXy0dcT6jxTBFR+aUVzHb ogWlpCOwxrTEZTI06VaPUYxNpR2K4IRvclwNEg5plHEvuSXyPJFTcVkly4LOMt3QgeK2 Pu+1FBKlhfTIX9licZjs/B59eLsLJP9jjRkXVnuFBcGqaTutL+m0erPOwx7gEA0mKeaD 994w== X-Gm-Message-State: AOAM530OG6ZAadLdcQKd1C70Jtt3/tU3kUZKkGp2JCQTSmDP2Ps1uejg tk2ASz6u1N6VgYcouMIDGnL5DvnBHRtQIg== X-Google-Smtp-Source: ABdhPJzbHO1gqa3TDhGhe/fWPJ+Ir2rpNvk31jcKqhNB7ZV0J4dRvPo3FwQta804qhiFoUoll4sQFQ== X-Received: by 2002:a17:902:6a82:b029:da:fc41:bafe with SMTP id n2-20020a1709026a82b02900dafc41bafemr47964111plk.20.1609341444744; Wed, 30 Dec 2020 07:17:24 -0800 (PST) Received: from mike-mac.lan (107-182-45-95.volcanocom.com. [107.182.45.95]) by smtp.gmail.com with ESMTPSA id k21sm40416422pfu.77.2020.12.30.07.17.23 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 30 Dec 2020 07:17:24 -0800 (PST) To: dmarc@ietf.org References: <9f6782b1-e85b-1a9c-9151-98feff7e18ea@mtcc.com> <140485eb-020f-4406-3f2f-e2c475ea51e5@mtcc.com> <5588dbbe-b876-ed80-c80f-792380e3718f@mtcc.com> <54dd9978-bcd1-6757-ad27-dcef6db6e5f7@mtcc.com> <937f1019-a028-308d-2a0f-1e720fd49dcd@mtcc.com> <53A477E1-3FE1-4D84-A930-BBC6AD006C05@wordtothewise.com> From: Michael Thomas Message-ID: <1c25c82e-db21-ba8b-cd56-3978019e32c4@mtcc.com> Date: Wed, 30 Dec 2020 07:17:21 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: <53A477E1-3FE1-4D84-A930-BBC6AD006C05@wordtothewise.com> Content-Type: multipart/alternative; boundary="------------591CB0CB3E3F1BBF5FFF5B6D" Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] auth-res vs. dmarc X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Dec 2020 15:17:27 -0000 This is a multi-part message in MIME format. --------------591CB0CB3E3F1BBF5FFF5B6D Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit On 12/30/20 7:06 AM, Laura Atkins wrote: > The auth-res result posted as an example of DMARC failing earlier in > this thread: > Authentication-Results:mx.google.com ; > dkim=passheader.i=@ietf.org header.s=ietf1 header.b=aayvF8Pg; > dkim=passheader.i=@ietf.org header.s=ietf1 header.b="PwU4/yuQ"; > dkim=neutral (body hash did not verify)header.i=@mrochek.com header.s=201712 header.b=PRr8Q7Zv; > spf=pass (google.com : domain ofdmarc-bounces@ietf.org designates 4.31.198.44 as permitted sender)smtp.mailfrom=dmarc-bounces@ietf.org; > dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=mrochek.com > The policy statement is right there: p=NONE. > No. That is not guaranteed whatsoever. It could say "(eat at Joe's)" and be valid. Mike --------------591CB0CB3E3F1BBF5FFF5B6D Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit


On 12/30/20 7:06 AM, Laura Atkins wrote:
The auth-res result posted as an example of DMARC failing earlier in this thread:
Authentication-Results: mx.google.com;
       dkim=pass header.i=@ietf.org header.s=ietf1 header.b=aayvF8Pg;
       dkim=pass header.i=@ietf.org header.s=ietf1 header.b="PwU4/yuQ";
       dkim=neutral (body hash did not verify) header.i=@mrochek.com header.s=201712 header.b=PRr8Q7Zv;
       spf=pass (google.com: domain of dmarc-bounces@ietf.org designates 4.31.198.44 as permitted sender) smtp.mailfrom=dmarc-bounces@ietf.org;
       dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=mrochek.com
The policy statement is right there: p=NONE.

No. That is not guaranteed whatsoever. It could say "(eat at Joe's)" and be valid.

Mike

--------------591CB0CB3E3F1BBF5FFF5B6D-- From nobody Wed Dec 30 07:32: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 D3E953A046B for ; Wed, 30 Dec 2020 07:32:04 -0800 (PST) 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 3IauQm5CVgX0 for ; Wed, 30 Dec 2020 07:32:03 -0800 (PST) Received: from mail-qk1-x72e.google.com (mail-qk1-x72e.google.com [IPv6:2607:f8b0:4864:20::72e]) (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 02B723A044A for ; Wed, 30 Dec 2020 07:32:02 -0800 (PST) Received: by mail-qk1-x72e.google.com with SMTP id v126so14103142qkd.11 for ; Wed, 30 Dec 2020 07:32:02 -0800 (PST) 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=iMVewMUogSRempzBbLqVCNYZ1NKOgoBSyHcNoHqCg3s=; b=fVR/uAMcEZkkBo3wZ1VU+jIAdVzShRZMdYBv82eqU3qjiM8PmORdjPO6lKSSfzBZ0r tIr7B0FHMLqntO3uQtdR2dJbT8p75ej55B4RBiqU+KUHkGL8rc1ZmVOvoHL4kPjcyWZv ySGd53EMGJlGLRe808y6hOFwzONdOafhBXCORqL9xz2bYr1BnnG48sw2B/MPs00nPOZa +wYmESQd6HnHl+nEUGIFQcQuud6M+jr2lUapPivmHSfqOnduo/nJ95GLD1GoegwCmHd8 pqF5hy2fQdRDQSBA/mOr7+qM59CnqgJFdXFXbwrx+dkl6oXcFPQ5j3Ee51wCofJQ0EA2 R1vQ== 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=iMVewMUogSRempzBbLqVCNYZ1NKOgoBSyHcNoHqCg3s=; b=S9C/33LzP1rDm5bs3mOoHxVHnPpRK16Ktls7uEpmOCsg6bZJ94KbJdVOmi0/Qd7zNs xcnJl1rFtMwyADI23TW3RALtjUHnTnwT4hkHwhF6eMbbH029BF+/cQCf1v1d5q3PLwlR gaqN0zasXQhdtp5sHdOaw+sODAphg6XbCOytE6d+4Vv3Oq8dcfOWqroEps/zDmEVYNZc W5hEKXO21z5ZaV5IR3bt3fjOnfRDI8I+EbX0dVrbhs7OGvR2sKjz/BOvuHl9oeLnzYZX ZYycSk2fYZfIfuCLeVwXgwNRyHTXog+s3PIVh6tMlSpwrjF3YGZQLmasXH4vbIssrRAq v+HQ== X-Gm-Message-State: AOAM530o0m3eNyVGtQ/qEhtlL98f51zHKmGWJW+4JUMM8RpZPyPiHjDV gDuELuk1nsquZGLPMSGOm4Rmr2wZihOpnOaZnHQe6geX3P4= X-Google-Smtp-Source: ABdhPJwIrqGaVmEnd/uC9cT5BaBGfEg5JaMeD4vlqqVvE+LvypBR64MzD5icf8XQrEMeG0+3tfOOjdpgDA/jAq1IvLg= X-Received: by 2002:a05:620a:10b7:: with SMTP id h23mr54534717qkk.249.1609342321894; Wed, 30 Dec 2020 07:32:01 -0800 (PST) MIME-Version: 1.0 References: <9f6782b1-e85b-1a9c-9151-98feff7e18ea@mtcc.com> <140485eb-020f-4406-3f2f-e2c475ea51e5@mtcc.com> <5588dbbe-b876-ed80-c80f-792380e3718f@mtcc.com> <54dd9978-bcd1-6757-ad27-dcef6db6e5f7@mtcc.com> <937f1019-a028-308d-2a0f-1e720fd49dcd@mtcc.com> <9c5f18c2-c5f6-4f66-a185-f684949738b5@mtcc.com> In-Reply-To: <9c5f18c2-c5f6-4f66-a185-f684949738b5@mtcc.com> From: Todd Herr Date: Wed, 30 Dec 2020 10:31:46 -0500 Message-ID: To: Michael Thomas Cc: IETF DMARC WG Content-Type: multipart/alternative; boundary="0000000000006b3e5005b7b0352f" Archived-At: Subject: Re: [dmarc-ietf] auth-res vs. dmarc X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Dec 2020 15:32:05 -0000 --0000000000006b3e5005b7b0352f Content-Type: text/plain; charset="UTF-8" On Wed, Dec 30, 2020 at 8:56 AM Michael Thomas wrote: > > On 12/30/20 5:48 AM, Todd Herr wrote: > > On Wed, Dec 30, 2020 at 4:42 AM Alessandro Vesely wrote: > >> On Tue 29/Dec/2020 22:02:20 +0100 Michael Thomas wrote: >> > On 12/29/20 12:47 PM, Todd Herr wrote: >> >>> Unless those values in parens are a MUST requirement, the dmarc=fail >> is >> >>> highly misleading. >> >> >> I agree with Michael here. When a (trusted) dmarc=fail is seen >> downstream, its consumers neither know what policy was specified nor >> whether it was honored. >> > > That depends on your definition of "downstream", I guess. > > MDAs and local clients (web and mobile) at the mailbox provider will have > the information they need. > > No they don't. I keep saying this, but you guys keep dismissing me. > Painting up "fail" for p=none is absolutely the wrong thing to do. It is > not what the user expects to see for a piece of mail that is perfectly > acceptable to the originating domain. This is an error or omission, full > stop. > > > I'm sorry, but I don't know that I've seen an example of painting up "fail" for p=none in my Gmail or Google Apps clients; it is possible you can share a screencap of an example of what you're referring to here, please? -- *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. --0000000000006b3e5005b7b0352f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Dec 30, 2020 at 8:56 AM Michael T= homas <mike@mtcc.com> wrote:
=
=20 =20 =20


On 12/30/20 5:48 AM, Todd Herr wrote:
=20
On Wed, Dec 30, 2020 at 4:42 AM Alessandro Vesely <vesely@ta= na.it> wrote:
On Tue 29/Dec/2= 020 22:02:20 +0100 Michael Thomas wrote:
> On 12/29/20 12:47 PM, Todd Herr wrote:
>>> Unless those values in parens are a MUST requirement, the dmarc=3Dfail is
>>> highly misleading.


I agree with Michael here.=C2=A0 When a (trusted) dmarc=3Dfail = is seen downstream, its consumers neither know what policy was specified nor whether it was honored.

That depends on your definition of "downstream", I guess.=C2=A0

MDAs and local clients (web and mobile) at the mailbox provider will have the information they need.

No they don't. I keep saying this, but you guys keep dismissing me. Painting up "fail" for p=3Dnone is absolutely the wrong= thing to do. It is not what the user expects to see for a piece of mail that is perfectly acceptable to the originating domain. This is an error or omission, full stop.



I'm sorry, but I = don't know that I've seen an example of painting up "fail"= ; for p=3Dnone in my Gmail or Google Apps clients; it is possible you can s= hare a screencap of an example of what you're referring to here, please= ?
=C2=A0
--

Todd = Herr | Sr. Technical Program Manager<= /div>
p: 7= 03.220.4153


This email and all data transmitted w= ith it contains confidential and/or proprietary information intended solely= for the use of individual(s) authorized to receive it. If you are not an i= ntended and authorized recipient you are hereby notified of any use, disclo= sure, copying or distribution of the information included in this transmiss= ion is prohibited and may be unlawful. Please immediately notify the sender= by replying to this email and then delete it from your system.

--0000000000006b3e5005b7b0352f-- From nobody Wed Dec 30 07:35: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 EE2373A046B for ; Wed, 30 Dec 2020 07:35:27 -0800 (PST) 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 99aAMhOboUuE for ; Wed, 30 Dec 2020 07:35:26 -0800 (PST) Received: from mail-qt1-x833.google.com (mail-qt1-x833.google.com [IPv6:2607:f8b0:4864:20::833]) (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 7F0E63A0489 for ; Wed, 30 Dec 2020 07:35:26 -0800 (PST) Received: by mail-qt1-x833.google.com with SMTP id g24so11099134qtq.12 for ; Wed, 30 Dec 2020 07:35:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=8CYS2wz7PTQldB9VjJlRI7S62+7SQyKNal+MMoXAhrg=; b=EXMbN6zK8pgStrWj9he2e4Gj1GXkPpxEhbgCf9wB7PqK6X7enTEu1U+4jvfvfplInn E6h1Oicxqp+8nyhDB9inxzq02G15Z71Oz9fJzpVRCxj3nLGSwSmgmbkkSin4E9jgaDrK qy8aSU+HHZPH9dptHkWP+kXem69eTOfWGGI8NxrglGhFa8/TXbwZnO+FchBS5Yw/Vedx h2va59rhSfrkXgkqzw0VGVwgm5dtBgQK5mKp/3obtceOgysrJLD7rd0sKwsRYnr5k5kc YC4KTxj7J5Zn7hJL6ykLeMhiu6W2AIUXgqpeEs1EnrYcfZNBEj/Y3oRb57Tx7Idel1M9 FH1A== 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=8CYS2wz7PTQldB9VjJlRI7S62+7SQyKNal+MMoXAhrg=; b=Dhkczwt79bSOotaEhRkYV+A+caCsv+1BpmM3qEgyE4AGZ1V3JuUIgfEzGbllcDx31/ sJ+6B9qZm9jYVahhJkjWkiGIXYVmiCOoDoO1KI9lYh4V4EhKvY1rkc6h+ihVgeRxSpTe KlzW+xHPvMRD9ykt7vx4v5lsuPPyqoV73LG9PKleuKPfVUGkoHq3I4a04i0AIzdUcFcf ww71r4PhF2eNhnukOFPKB4KMJ7cyBbJaJYG/jUG0lwMyeLww06tFlVF7S/H7zBbcth4u 8CK/OG3xyxiqBkWkPj0/UilBlD+EAWtWMq9mGdSyRNV7Ajf/lTk6N2q0w+hVoS1Rw9AR +UrA== X-Gm-Message-State: AOAM532mKhvCY5lJeiCVex2CqsunMQLmAfLbKSkciKRUl6HUJ9rzldlp BbrcSAbWdyVriJnb+n3fTn2jGs5GAVsTMO/hICRrSkpbCbs= X-Google-Smtp-Source: ABdhPJzWq8dGGpYvLAwu92WuVa2X63IVZSoboULYftucfM5C9pK3N+LV5Q3GqLgNWyKB8m5npWYXnqFo9XKyMRKrDxE= X-Received: by 2002:ac8:5808:: with SMTP id g8mr53211810qtg.208.1609342525293; Wed, 30 Dec 2020 07:35:25 -0800 (PST) MIME-Version: 1.0 References: <9f6782b1-e85b-1a9c-9151-98feff7e18ea@mtcc.com> <140485eb-020f-4406-3f2f-e2c475ea51e5@mtcc.com> <5588dbbe-b876-ed80-c80f-792380e3718f@mtcc.com> <54dd9978-bcd1-6757-ad27-dcef6db6e5f7@mtcc.com> <937f1019-a028-308d-2a0f-1e720fd49dcd@mtcc.com> <72e20c17-e991-e82a-9120-a27097e3ac58@mtcc.com> In-Reply-To: <72e20c17-e991-e82a-9120-a27097e3ac58@mtcc.com> From: Todd Herr Date: Wed, 30 Dec 2020 10:35:09 -0500 Message-ID: To: IETF DMARC WG Content-Type: multipart/alternative; boundary="0000000000008adcf405b7b041f8" Archived-At: Subject: Re: [dmarc-ietf] auth-res vs. dmarc X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Dec 2020 15:35:28 -0000 --0000000000008adcf405b7b041f8 Content-Type: text/plain; charset="UTF-8" On Wed, Dec 30, 2020 at 9:01 AM Michael Thomas wrote: > > On 12/30/20 5:48 AM, Todd Herr wrote: > > > I propose to add two new result name codes, named after the policy >> requests: >> >> dmarc=quarantine, and >> >> dmarc=reject (of course, you only see this if the filter didn't honor >> the request). >> >> > I do not support this, because quarantine, reject, and none are not > Authentication Results, but are instead both policy requests and > disposition decisions. > > Then we should remove DMARC from auth-res altogether because it is not an > authentication mechanism. Either we fully support DMARC in auth-res or > remove it. This half-assed state of unlessness serves nobody. > > > I disagree. DMARC has rules that determine whether or not a message is deemed to be authenticated - did it pass SPF or DKIM and did it do so with a domain that aligns with the RFC5322.From domain. The currently valid states for those rules are pass, fail, temperror, and permerror. Policy and disposition (none, quarantine, reject) apply to decisions made based on the authentication results; they are not states for the authentication checks themselves. -- *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. --0000000000008adcf405b7b041f8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Dec 30, 2020 at 9:01 AM Michael T= homas <mike@mtcc.com> wrote:
=
=20 =20 =20


On 12/30/20 5:48 AM, Todd Herr wrote:
=20

I propose to add two new result name codes, named after the policy requests:

=C2=A0 =C2=A0 dmarc=3Dquarantine, and

=C2=A0 =C2=A0 dmarc=3Dreject (of course, you only see this if t= he filter didn't honor the request).


I do not support this, because quarantine, reject, and none are not Authentication Results, but are instead both policy requests and disposition decisions.=C2=A0

Then we should remove DMARC from auth-res altogether because it is not an authentication mechanism. Either we fully support DMARC in auth-res or remove it. This half-assed state of unlessness serves nobody.


I disagree. DMARC has rules that det= ermine whether or not a message is deemed to be authenticated - did it pass= SPF or DKIM and did it do so with a domain that aligns with the RFC5322.Fr= om domain. The currently valid states for those rules are pass, fail, tempe= rror, and permerror.

Policy and disposition (none,= quarantine, reject) apply to decisions made based on the authentication re= sults; they are not states for the authentication checks themselves.=C2=A0<= /div>

--

Todd Herr= | Sr. Technical Program Manager
e: <= a href=3D"mailto:todd.herr@valimail.com" target=3D"_blank">todd.herr@valima= il.com
p: 703.2= 20.4153

=


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

--0000000000008adcf405b7b041f8-- From nobody Wed Dec 30 07:36: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 8C48E3A048B for ; Wed, 30 Dec 2020 07:36:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, 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=mtcc.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 5srGNa0XPc-J for ; Wed, 30 Dec 2020 07:36:03 -0800 (PST) Received: from mail-pf1-x431.google.com (mail-pf1-x431.google.com [IPv6:2607:f8b0:4864:20::431]) (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 E65E13A0489 for ; Wed, 30 Dec 2020 07:36:02 -0800 (PST) Received: by mail-pf1-x431.google.com with SMTP id s21so9840135pfu.13 for ; Wed, 30 Dec 2020 07:36:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mtcc.com; s=fluffulence; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=dg34AJ02zqITVxvI94LFSbQgpFW0xjR9/D5MUqjmRUE=; b=g3LfGnwUh+G7+oHe/lAfnJc2PQ4vBZAMKQa5IR3HagX9hmeBXkmvOEO/alzwP32nLP 6jTcGUBzKOAfe3WYzv3EUo6fnX8nEhWbWcG4J8r/MwBiXIdghBvq984oaAGt7J/rWP5j Ho4uKSlr9uvamlTSmistSddodMIswy83EpKK+8ysTOj9mljsgZR0uyJNrUFifrY3hSXg UaQDa01ubygS+Q/syIu6o7AAd61lvFplfPODO+9qwZLV5ogUmz/yaCHKXvKt8bRixVGQ tIv44bv1n/ZviQeAsQr+eF9Ge6UHoY9ndw5OB5U3zAnyDX8JvoVpmjfrxKDtwFhdMMcj 70sQ== 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=dg34AJ02zqITVxvI94LFSbQgpFW0xjR9/D5MUqjmRUE=; b=q9gktGMlckuAUTzFbWnquq8pcFPOYfSGCFbEqkg0lEw9zTplNnbeCyzp9OxChKGWGz rLrEE6dyAEBb8CJMzstAdGBev4Qb6gf7ry+R0dJwz2At72FAK56kIB/AR+1VrooNBUDy u5MJhjetkBQa5TV4fA8oajGh3+Aj+v9vfhkeAbCo76yGFskq5ayW5sDRten4mj7tysuo PB20feVK/uFoFXNJIfFgRxTE+VhB+BU5u0Q+KZ9hZ2QlpPFc9TN54Q4jrV7nkQDARaYJ DhaSEEFLkeWhVnY8ps8+RpPofzO6wPIRUZyAXaDanSuFi1s7znHU7E9I/X75jrJgVNg1 7gsA== X-Gm-Message-State: AOAM5316/CvwtrTLdxCNBwChsQwKUucKnoh3B5RuK694rZdVeaZFERPP C//zjAEZBhn/4f1mU5nYsqoNeY9Aevu8qQ== X-Google-Smtp-Source: ABdhPJxDYVyDmjqQiKuguIDvUTKKtjwhVgxiSH5YBlCSbVZ4qVh5DmzfH6AY7P+KRjMwzYQjIPp6uQ== X-Received: by 2002:a63:f64c:: with SMTP id u12mr35277636pgj.98.1609342561926; Wed, 30 Dec 2020 07:36:01 -0800 (PST) Received: from mike-mac.lan (107-182-45-95.volcanocom.com. [107.182.45.95]) by smtp.gmail.com with ESMTPSA id v3sm8480328pjn.7.2020.12.30.07.36.00 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 30 Dec 2020 07:36:01 -0800 (PST) To: Todd Herr Cc: IETF DMARC WG References: <9f6782b1-e85b-1a9c-9151-98feff7e18ea@mtcc.com> <140485eb-020f-4406-3f2f-e2c475ea51e5@mtcc.com> <5588dbbe-b876-ed80-c80f-792380e3718f@mtcc.com> <54dd9978-bcd1-6757-ad27-dcef6db6e5f7@mtcc.com> <937f1019-a028-308d-2a0f-1e720fd49dcd@mtcc.com> <9c5f18c2-c5f6-4f66-a185-f684949738b5@mtcc.com> From: Michael Thomas Message-ID: <326d993e-0d92-206b-dd94-bef21ddfbaaa@mtcc.com> Date: Wed, 30 Dec 2020 07:35:59 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------2C25002D7613A44190420AA2" Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] auth-res vs. dmarc X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Dec 2020 15:36:07 -0000 This is a multi-part message in MIME format. --------------2C25002D7613A44190420AA2 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 12/30/20 7:31 AM, Todd Herr wrote: > On Wed, Dec 30, 2020 at 8:56 AM Michael Thomas > wrote: > > > On 12/30/20 5:48 AM, Todd Herr wrote: >> On Wed, Dec 30, 2020 at 4:42 AM Alessandro Vesely > > wrote: >> >> On Tue 29/Dec/2020 22:02:20 +0100 Michael Thomas wrote: >> > On 12/29/20 12:47 PM, Todd Herr wrote: >> >>> Unless those values in parens are a MUST requirement, the >> dmarc=fail is >> >>> highly misleading. >> >> >> I agree with Michael here.  When a (trusted) dmarc=fail is >> seen downstream, its consumers neither know what policy was >> specified nor whether it was honored. >> >> >> That depends on your definition of "downstream", I guess. >> >> MDAs and local clients (web and mobile) at the mailbox provider >> will have the information they need. > > No they don't. I keep saying this, but you guys keep dismissing > me. Painting up "fail" for p=none is absolutely the wrong thing to > do. It is not what the user expects to see for a piece of mail > that is perfectly acceptable to the originating domain. This is an > error or omission, full stop. > > > > I'm sorry, but I don't know that I've seen an example of painting up > "fail" for p=none in my Gmail or Google Apps clients; it is possible > you can share a screencap of an example of what you're referring to > here, please? > I already said there is a thunderbird extension called dkim-verify that does exactly that. It says "DMARC: fail". That is highly misleading to the user. Mike --------------2C25002D7613A44190420AA2 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit


On 12/30/20 7:31 AM, Todd Herr wrote:
On Wed, Dec 30, 2020 at 8:56 AM Michael Thomas <mike@mtcc.com> wrote:


On 12/30/20 5:48 AM, Todd Herr wrote:
On Wed, Dec 30, 2020 at 4:42 AM Alessandro Vesely <vesely@tana.it> wrote:
On Tue 29/Dec/2020 22:02:20 +0100 Michael Thomas wrote:
> On 12/29/20 12:47 PM, Todd Herr wrote:
>>> Unless those values in parens are a MUST requirement, the dmarc=fail is
>>> highly misleading.


I agree with Michael here.  When a (trusted) dmarc=fail is seen downstream, its consumers neither know what policy was specified nor whether it was honored.

That depends on your definition of "downstream", I guess. 

MDAs and local clients (web and mobile) at the mailbox provider will have the information they need.

No they don't. I keep saying this, but you guys keep dismissing me. Painting up "fail" for p=none is absolutely the wrong thing to do. It is not what the user expects to see for a piece of mail that is perfectly acceptable to the originating domain. This is an error or omission, full stop.



I'm sorry, but I don't know that I've seen an example of painting up "fail" for p=none in my Gmail or Google Apps clients; it is possible you can share a screencap of an example of what you're referring to here, please?
 

I already said there is a thunderbird extension called dkim-verify that does exactly that. It says "DMARC: fail". That is highly misleading to the user.

Mike

--------------2C25002D7613A44190420AA2-- From nobody Wed Dec 30 07:40: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 C9F993A07C8 for ; Wed, 30 Dec 2020 07:40:34 -0800 (PST) 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 yp-YOXCf7wYm for ; Wed, 30 Dec 2020 07:40:33 -0800 (PST) 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 CC4C43A048B for ; Wed, 30 Dec 2020 07:40:32 -0800 (PST) Received: by mail-qv1-xf2d.google.com with SMTP id l7so7842468qvt.4 for ; Wed, 30 Dec 2020 07:40:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=7kvEWmdCi25ELMbL81M+HEyWCDaEiXMqNYKSuFfP97o=; b=OUc8qR3vOP2Vp2TMhfmZe1hcIdbM5eQBcm8whg70QkYfga8Het8Ojdh4H34F+T1dXz F9KyEE8t0Hk6yFaBfHtbaD8519ndKOu0MtTCafgbpVO1MF4cadGU66ZrYc9sqoT0qThs fE4yDsT/j6zmVFUyiYsftRG9mGGolYyd2fYF34VGJIywXcUxfMxPW8P9pZKwf7a9L564 2gt/mJK3e/T+mNlj1Ys6GRjHOSYEglLGCO0bkPY1jRvyoRdr+8PwTF1jSFx0zSJNWQv0 3civDHMzXoIQXVloEOcFyqMNpzH/KkyUSAA6Si5SE06OwuimvoUskwWDxVFANh2zqtbN m4qw== 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=7kvEWmdCi25ELMbL81M+HEyWCDaEiXMqNYKSuFfP97o=; b=an64J8bRV7j5PHSuUZOLTLafdGcuAS3bfz0uwS2xyUJ8RQ3fu8dCr7HiBbUydmIEZR leLefiOLnez7L3nc684bv3n7f0RLxwQ9ZKT/TMj78BDgokOdP9lMkS4tqTPw/rVe7JJX zbYa/PRkn9gMau4WRonU21yZloSDZPHNSWhdKPAxeCBIurgdjLNZKQuWiE/+05Eh6TEe OEb63pv5skYEgVIglhqb5gJXWgkFIuu3RPdVZb5LJQRip1KiW2u6K9iF+5zTR7j6Qywt p7sQ5GgE8+U5FAo4xqJE0XvMFm8xST7m8UgEYdIHP0KV1xyHbKB3JG4YWxS1n4RVo2Ju +FJA== X-Gm-Message-State: AOAM53183x3aG0dUUKSy0iMqXo2GSnmSxyni1C/GLgSmMBvdHu1HifsA OP6uL7hfg4QJKRZECD1jMXPwAQRyXbCAUM5G0WlU736sF7M= X-Google-Smtp-Source: ABdhPJw78lS2RISBgCzRP81MIa+QjO4zULXxudLS50ubOuuS5DZvzqQRUdrRgy3LKyhl52rvI0hTLYvzB3o5/Hrac0A= X-Received: by 2002:a05:6214:684:: with SMTP id r4mr50098670qvz.54.1609342831364; Wed, 30 Dec 2020 07:40:31 -0800 (PST) MIME-Version: 1.0 References: <9f6782b1-e85b-1a9c-9151-98feff7e18ea@mtcc.com> <140485eb-020f-4406-3f2f-e2c475ea51e5@mtcc.com> <5588dbbe-b876-ed80-c80f-792380e3718f@mtcc.com> <54dd9978-bcd1-6757-ad27-dcef6db6e5f7@mtcc.com> <937f1019-a028-308d-2a0f-1e720fd49dcd@mtcc.com> <9c5f18c2-c5f6-4f66-a185-f684949738b5@mtcc.com> <326d993e-0d92-206b-dd94-bef21ddfbaaa@mtcc.com> In-Reply-To: <326d993e-0d92-206b-dd94-bef21ddfbaaa@mtcc.com> From: Todd Herr Date: Wed, 30 Dec 2020 10:40:15 -0500 Message-ID: To: IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000c9213805b7b05336" Archived-At: Subject: Re: [dmarc-ietf] auth-res vs. dmarc X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Dec 2020 15:40:35 -0000 --000000000000c9213805b7b05336 Content-Type: text/plain; charset="UTF-8" On Wed, Dec 30, 2020 at 10:36 AM Michael Thomas wrote: > > On 12/30/20 7:31 AM, Todd Herr wrote: > > On Wed, Dec 30, 2020 at 8:56 AM Michael Thomas wrote: > >> >> On 12/30/20 5:48 AM, Todd Herr wrote: >> >> >> MDAs and local clients (web and mobile) at the mailbox provider will have >> the information they need. >> >> No they don't. I keep saying this, but you guys keep dismissing me. >> Painting up "fail" for p=none is absolutely the wrong thing to do. It is >> not what the user expects to see for a piece of mail that is perfectly >> acceptable to the originating domain. This is an error or omission, full >> stop. >> >> >> > I'm sorry, but I don't know that I've seen an example of painting up > "fail" for p=none in my Gmail or Google Apps clients; it is possible you > can share a screencap of an example of what you're referring to here, > please? > > > I already said there is a thunderbird extension called dkim-verify that > does exactly that. It says "DMARC: fail". That is highly misleading to the > user. > > > I see. I wrote "MDAs and local clients (web and mobile) at the mailbox provider", and I was referring to things such as Gmail's web client, Gmail's mobile client, etc. You are talking about an extension for Thunderbird, which is different from what I'm talking about. Thank you for the clarification. -- *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. --000000000000c9213805b7b05336 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Dec 30, 2020 at 10:36 AM Michael = Thomas <mike@mtcc.com> wrote:
=20 =20 =20


On 12/30/20 7:31 AM, Todd Herr wrote:
=20
On Wed, Dec 30, 2020 at 8:56 AM Michael Thomas <mike@mtcc.= com> wrote:


On 12/30/20 5:48 AM, Todd Herr wrote:

MDAs and local clients (web and mobile) at the mailbox provider will have the information they need.

No they don't. I keep saying this, but you guys keep dismissing me. Painting up "fail" for p=3Dnone is absolutely the wrong thing to do. It is not what the user expects to see for a piece of mail that is perfectly acceptable to the originating domain. This is an error or omission, full stop.



I'm sorry, but I don't know that I've seen an ex= ample of painting up "fail" for p=3Dnone in my Gmail or Google= Apps clients; it is possible you can share a screencap of an example of what you're referring to here, please?
=C2=A0

I already said there is a thunderbird extension called dkim-verify that does exactly that. It says "DMARC: fail". = That is highly misleading to the user.



I see.=C2=A0

I wrote "MDAs and local clients (web and mobile) at t= he mailbox provider",=C2=A0 and I was referring to things such as Gmai= l's web client, Gmail's=C2=A0mobile client, etc.=C2=A0
You are talking about an extension for Thunderbird, which is d= ifferent from what I'm talking about.=C2=A0

Th= ank you for the clarification.

--

<= span style=3D"vertical-align:baseline;white-space:pre-wrap;font-size:small;= font-family:Arial">Todd Herr | Sr. Techni= cal 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 rece= ive it. If you are not an intended and authorized recipient you are hereby = notified of any use, disclosure, copying or distribution of the information= included in this transmission is prohibited and may be unlawful. Please im= mediately notify the sender by replying to this email and then delete it fr= om your system.

--000000000000c9213805b7b05336-- From nobody Wed Dec 30 07:41: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 CE7163A07F0 for ; Wed, 30 Dec 2020 07:41:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, 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=mtcc.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 j9CEC1zofYf9 for ; Wed, 30 Dec 2020 07:41:40 -0800 (PST) Received: from mail-pg1-x533.google.com (mail-pg1-x533.google.com [IPv6:2607:f8b0:4864:20::533]) (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 76CC83A07EA for ; Wed, 30 Dec 2020 07:41:40 -0800 (PST) Received: by mail-pg1-x533.google.com with SMTP id n25so11567916pgb.0 for ; Wed, 30 Dec 2020 07:41:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mtcc.com; s=fluffulence; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=n3nCZqlDWXUPzlr9o6uU4zC4xNwo4rMTfhbMw0O6ZuI=; b=nkb44L1mvSzgJ5M3KZ21VQJia7TZRW18/8D1ydkizpdjzK9B6t9TublmLHdJcs/Fd4 zdGXPURD9rrbboRQq/S+sxJ408COyXCJaNjPMoyYpMN/9jPBL+JkAZqGKdo+jNQXWthO xpZRgBD8PFDE4J8FwFNmG2tyTGQb3pvP8p3Lh/8QxKHLVv5UFeSw+AXJHFXuPgOGQQBM ZYQ1qn0YTaBSfvlj4MCNpbTKssUc7UMwjZeI4gMtkTIMaCjK1mWekyupIwQSXUM0k3cz d3ZuW0sWcMQ17KwPRGFUReDkZ1FzF1WKwVxJmE7qvAPc3quShPm+FPxwGq3lDzq1xiZk CXsQ== 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=n3nCZqlDWXUPzlr9o6uU4zC4xNwo4rMTfhbMw0O6ZuI=; b=DmIPp7WDQpsDB2UEp7ZCKrneUplSqo3XTVpR26QctLrnIhZ4dMH0LB3zvVCDU8vMPr s2wFAGd5RVc8KANlY3BCDl+di3wBxun0aP15mrbTSDY0QlcEcapYGazsDQG6m7OquRdR tUEGCilzR3UElcjtwbtzTLpvJsDXYIo7+YSZUfBNKWbTW2Ju0+/Y4aMl9QCy+GLabq/d oJiseEgIUwwTzisVYEezAnmTO4qgF05czESSU5Avxlya+SVBYGvp5tLJimRhWbC9/lm+ /VQniQwrBXQaElpwIgfg0wxmmrcW8WXdkgFwnuo3D+pjaSe0lqSkvWG3tJrAzPUiVEQ+ MrMw== X-Gm-Message-State: AOAM532LsmKvz6fQl7EQEeUOQ7EgSosNhvhF5xflLcLvbnvHsCwDgIPk hgarYemoZwUtR6L4k6Hg3b+79h78gccugw== X-Google-Smtp-Source: ABdhPJwpHuYP9+FpG6Bqq6aEsYysOYCJrUZCGm41pD94MguXuCT/d82SAOSG1q1p4wiYmkOLMkgC+g== X-Received: by 2002:a65:488d:: with SMTP id n13mr16326284pgs.315.1609342899605; Wed, 30 Dec 2020 07:41:39 -0800 (PST) Received: from mike-mac.lan (107-182-45-95.volcanocom.com. [107.182.45.95]) by smtp.gmail.com with ESMTPSA id z23sm35345073pfj.143.2020.12.30.07.41.38 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 30 Dec 2020 07:41:38 -0800 (PST) To: dmarc@ietf.org References: <9f6782b1-e85b-1a9c-9151-98feff7e18ea@mtcc.com> <140485eb-020f-4406-3f2f-e2c475ea51e5@mtcc.com> <5588dbbe-b876-ed80-c80f-792380e3718f@mtcc.com> <54dd9978-bcd1-6757-ad27-dcef6db6e5f7@mtcc.com> <937f1019-a028-308d-2a0f-1e720fd49dcd@mtcc.com> <72e20c17-e991-e82a-9120-a27097e3ac58@mtcc.com> From: Michael Thomas Message-ID: <7863d250-f56a-1fe1-44ee-fbc7486d48b4@mtcc.com> Date: Wed, 30 Dec 2020 07:41:37 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------0F66340D67DA2F0A91108D3F" Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] auth-res vs. dmarc X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Dec 2020 15:41:42 -0000 This is a multi-part message in MIME format. --------------0F66340D67DA2F0A91108D3F Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 12/30/20 7:35 AM, Todd Herr wrote: > On Wed, Dec 30, 2020 at 9:01 AM Michael Thomas > wrote: > > > On 12/30/20 5:48 AM, Todd Herr wrote: >> >> I propose to add two new result name codes, named after the >> policy requests: >> >>     dmarc=quarantine, and >> >>     dmarc=reject (of course, you only see this if the filter >> didn't honor the request). >> >> >> I do not support this, because quarantine, reject, and none are >> not Authentication Results, but are instead both policy requests >> and disposition decisions. >> > Then we should remove DMARC from auth-res altogether because it is > not an authentication mechanism. Either we fully support DMARC in > auth-res or remove it. This half-assed state of unlessness serves > nobody. > > > I disagree. DMARC has rules that determine whether or not a message is > deemed to be authenticated - did it pass SPF or DKIM and did it do so > with a domain that aligns with the RFC5322.From domain. The currently > valid states for those rules are pass, fail, temperror, and permerror. > > Policy and disposition (none, quarantine, reject) apply to decisions > made based on the authentication results; they are not states for the > authentication checks themselves. > DMARC != Auth-res. Auth-res provides all kinds of useful information than just pass/fail. For DMARC Auth-res should provide what the policy was at a bare minimum. But none of this seems to have any normative language anywhere which is a problem unto itself. DMARC in auth-res seems to be an orphan. Mike --------------0F66340D67DA2F0A91108D3F Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit


On 12/30/20 7:35 AM, Todd Herr wrote:
On Wed, Dec 30, 2020 at 9:01 AM Michael Thomas <mike@mtcc.com> wrote:


On 12/30/20 5:48 AM, Todd Herr wrote:

I propose to add two new result name codes, named after the policy requests:

    dmarc=quarantine, and

    dmarc=reject (of course, you only see this if the filter didn't honor the request).


I do not support this, because quarantine, reject, and none are not Authentication Results, but are instead both policy requests and disposition decisions. 

Then we should remove DMARC from auth-res altogether because it is not an authentication mechanism. Either we fully support DMARC in auth-res or remove it. This half-assed state of unlessness serves nobody.


I disagree. DMARC has rules that determine whether or not a message is deemed to be authenticated - did it pass SPF or DKIM and did it do so with a domain that aligns with the RFC5322.From domain. The currently valid states for those rules are pass, fail, temperror, and permerror.

Policy and disposition (none, quarantine, reject) apply to decisions made based on the authentication results; they are not states for the authentication checks themselves. 

DMARC != Auth-res. Auth-res provides all kinds of useful information than just pass/fail. For DMARC Auth-res should provide what the policy was at a bare minimum. But none of this seems to have any normative language anywhere which is a problem unto itself. DMARC in auth-res seems to be an orphan.

Mike

--------------0F66340D67DA2F0A91108D3F-- From nobody Wed Dec 30 07:48: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 A60823A0825 for ; Wed, 30 Dec 2020 07:48:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, 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=mtcc.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 FbnZ2RV4N-sY for ; Wed, 30 Dec 2020 07:48:00 -0800 (PST) Received: from mail-pj1-x1031.google.com (mail-pj1-x1031.google.com [IPv6:2607:f8b0:4864:20::1031]) (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 8A4563A0803 for ; Wed, 30 Dec 2020 07:48:00 -0800 (PST) Received: by mail-pj1-x1031.google.com with SMTP id j13so3875632pjz.3 for ; Wed, 30 Dec 2020 07:48:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mtcc.com; s=fluffulence; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=2hlnBE3AFODycG+Cq96LfcGh2WrhA45Zcu0lxOtFSl0=; b=J4B9e5WHNCtkIluPbzclBRn5nDSGMKPrapsyw7w0MDRCPRrdg0c336xRV4jAPo+a3J J03/mFRNA3dXxxA76R+TIoE91grFU9uObvbSGXjDF8GHQnBoLLE99Lbl03xx/fMn7TR0 W4k8P/sZpEbNaKb7yDLfh1LO4//amO1YEHMcir0Vp4FCKVtLlIauRBP+DQuHbCtZSQUj wCiO7X6cQcZGpVhzFn/dH3Nbg4MwBlQ0Tfok2YD7t+N/kyuS3gr0jM99MYUJ9PQ68YSP gRYuYnYecO7L80xthcXPWoW3vGi85ZZQo+I/Fq1koxC5jI1ZnzHvD74focPnFEgPTwhU k+sQ== 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=2hlnBE3AFODycG+Cq96LfcGh2WrhA45Zcu0lxOtFSl0=; b=tvWpRfYSiSB1QBlsjsPeHQ1EawIDdrp+lQX9x97E9wceAY1tD6pJG6Kjqr2tMYWjSV CVFB+b9yXVREOxKnd8qHMsWcZPONrO+kshmKe/IMrCR21oRaobWZCuvRc+GDVE80kAod 0xSJ4meSVVQJH+4wa+kmN1qiwxuy/bQo6rkxycFreYSRyKzhyKGAa71YEbpCADVj0d+y WXxpMYZFc3HiTpVD7bbfKlGbtb35RFkBKiP1zf/Krvb3XX/HVW5VVnIDPBKHWlZCyg09 CIdxH8DOOHLQQ/EJ2vNzc+lwK98DqELkBfbz4uES/H5f8ndt7zkLGeRKi39KBa06Z3Um 96HQ== X-Gm-Message-State: AOAM533/PF1DXXgLyz45aX3SETO2O3JyhpIBUBWolETJ75HzkxVTRnO8 ekyYkd5Gkw0/6SFP+XvbWEL8/Uu/eB1pxA== X-Google-Smtp-Source: ABdhPJyancqomndae6/KMN8TKJnHLaVttHGIbJeYhEj/MpUhBbgTjZqK5vAgjOgcbcGqoPDBhPJH6g== X-Received: by 2002:a17:902:bd8d:b029:da:fcd1:664 with SMTP id q13-20020a170902bd8db02900dafcd10664mr54206766pls.30.1609343279457; Wed, 30 Dec 2020 07:47:59 -0800 (PST) Received: from mike-mac.lan (107-182-45-95.volcanocom.com. [107.182.45.95]) by smtp.gmail.com with ESMTPSA id a131sm37653630pfd.171.2020.12.30.07.47.58 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 30 Dec 2020 07:47:58 -0800 (PST) To: dmarc@ietf.org References: <9f6782b1-e85b-1a9c-9151-98feff7e18ea@mtcc.com> <140485eb-020f-4406-3f2f-e2c475ea51e5@mtcc.com> <5588dbbe-b876-ed80-c80f-792380e3718f@mtcc.com> <54dd9978-bcd1-6757-ad27-dcef6db6e5f7@mtcc.com> <937f1019-a028-308d-2a0f-1e720fd49dcd@mtcc.com> <9c5f18c2-c5f6-4f66-a185-f684949738b5@mtcc.com> <326d993e-0d92-206b-dd94-bef21ddfbaaa@mtcc.com> From: Michael Thomas Message-ID: <06474cf1-105a-b6fb-a7b5-de6f7dff761d@mtcc.com> Date: Wed, 30 Dec 2020 07:47:57 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------198B8C2BAD158792C6FE1B97" Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] auth-res vs. dmarc X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Dec 2020 15:48:02 -0000 This is a multi-part message in MIME format. --------------198B8C2BAD158792C6FE1B97 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 12/30/20 7:40 AM, Todd Herr wrote: > I already said there is a thunderbird extension called dkim-verify > that does exactly that. It says "DMARC: fail". That is highly > misleading to the user. > > > I see. > > I wrote "MDAs and local clients (web and mobile) at the mailbox > provider",  and I was referring to things such as Gmail's web client, > Gmail's mobile client, etc. > > You are talking about an extension for Thunderbird, which is different > from what I'm talking about. > > Thank you for the clarification. > This would be a problem for any MUA. That's the point. It's not different, it's the exact same problem for every MUA. There is no normative mechanism that gives anything downstream from the DMARC check producing the auth-res to be able to use that information correctly. And we sure don't want billions of MUA's doing DMARC checks on their own because of the inadequacy of auth-res. There is code in that extension to do exactly that. If that were widespread, it would be disastrous. Mike --------------198B8C2BAD158792C6FE1B97 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit


On 12/30/20 7:40 AM, Todd Herr wrote:
I already said there is a thunderbird extension called dkim-verify that does exactly that. It says "DMARC: fail". That is highly misleading to the user.


I see. 

I wrote "MDAs and local clients (web and mobile) at the mailbox provider",  and I was referring to things such as Gmail's web client, Gmail's mobile client, etc. 

You are talking about an extension for Thunderbird, which is different from what I'm talking about. 

Thank you for the clarification.

This would be a problem for any MUA. That's the point. It's not different, it's the exact same problem for every MUA. There is no normative mechanism that gives anything downstream from the DMARC check producing the auth-res to be able to use that information correctly. And we sure don't want billions of MUA's doing DMARC checks on their own because of the inadequacy of auth-res. There is code in that extension to do exactly that. If that were widespread, it would be disastrous.

Mike

--------------198B8C2BAD158792C6FE1B97-- From nobody Wed Dec 30 08:22: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 2F1913A091A for ; Wed, 30 Dec 2020 08:22:21 -0800 (PST) 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 JjkPF8X9moOC for ; Wed, 30 Dec 2020 08:22:19 -0800 (PST) Received: from mail-qv1-xf36.google.com (mail-qv1-xf36.google.com [IPv6:2607:f8b0:4864:20::f36]) (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 A828B3A090D for ; Wed, 30 Dec 2020 08:22:19 -0800 (PST) Received: by mail-qv1-xf36.google.com with SMTP id p5so7888737qvs.7 for ; Wed, 30 Dec 2020 08:22:19 -0800 (PST) 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=VvYJ7jAdOycCkMA8aYJoeQLMchFenjed8XG0AmYeFq0=; b=RpvMIBCHJm4Le22qS+ODzFFc8u5ohuf7poiKy6bz1gzHgajmkLKgnYQZuqZBoy46qB 0V5qa9Vy4FoUBbD+3LExX5NtYpGghRoMiBPpGG4DQcrta2dAHywluUUjKBRjWUeA2wL9 Eo8BHL/7H2gg7U5DF0YxBkN2nQaIQO/0TXaNvFnqZvv629EkXMvr3CZ2TwLpCsjx2Ikq /65m3G4B4ulqUCPiIz/9cAxQ7hHFjNbKJwsF/rOUrBazLew9oaxGycsrUJdCDtSktERa /hHuFJJ864hiEr70nk0UMeAYAtMw4xKWzrKZr+izq14KCjD9UUvkZaTRg+a9kj0AW6dF TMTQ== 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=VvYJ7jAdOycCkMA8aYJoeQLMchFenjed8XG0AmYeFq0=; b=FV/6qF/bCGHL42YQBKsrFVm2rCiw7PELM6I7v7LnX5PeXSKpotc5R4Ci3oY00wq+gC 86lRwFwmH3DTkxEfuLCbMn5XHZSuudVRqXq7P7iaK64rfQiIigaX0YFRhhacX/SJ9n1k LygYZ0cOGgT++1tdtzhiVqtoAhSyERDxlv1w3ka7S6J96I3dveqvMnqsVxgF4Zdz6F5Q uWNO3POAeHdrTUtUa/Q+5pk0+tk6V7YUlG2Mf4Uvz3OT+RsUFhkOriJrwRbe6FFBfXS1 wEdco8ua8KWBGm44udLEAwNiH04aJ0nUQsgw17z7+NV2tSS7KEcTvg1VAUp5WdaCsgcv ImWg== X-Gm-Message-State: AOAM533tS/evv64Ws5KDSe11KeGlOIwsVGDlMgw9QyDhN8Kgh1stah+a 99JaWie0tVOEptYl8H+C59/aKpQI1IkXbNQDwkUBgVLC35U= X-Google-Smtp-Source: ABdhPJxWazkK2p5ppPoQOxRbHrBBx/T4Y7EOHoHLg2ufhwmYjsDgksRJmCSniDBvYDIjavEJ2VeUin+bAzx1RZo3tew= X-Received: by 2002:a0c:bd9f:: with SMTP id n31mr56659693qvg.42.1609345338540; Wed, 30 Dec 2020 08:22:18 -0800 (PST) MIME-Version: 1.0 References: <9f6782b1-e85b-1a9c-9151-98feff7e18ea@mtcc.com> <140485eb-020f-4406-3f2f-e2c475ea51e5@mtcc.com> <5588dbbe-b876-ed80-c80f-792380e3718f@mtcc.com> <54dd9978-bcd1-6757-ad27-dcef6db6e5f7@mtcc.com> <937f1019-a028-308d-2a0f-1e720fd49dcd@mtcc.com> <72e20c17-e991-e82a-9120-a27097e3ac58@mtcc.com> <7863d250-f56a-1fe1-44ee-fbc7486d48b4@mtcc.com> In-Reply-To: <7863d250-f56a-1fe1-44ee-fbc7486d48b4@mtcc.com> From: Dotzero Date: Wed, 30 Dec 2020 11:22:07 -0500 Message-ID: To: Michael Thomas Cc: IETF DMARC WG Content-Type: multipart/alternative; boundary="00000000000039870705b7b0e969" Archived-At: Subject: Re: [dmarc-ietf] auth-res vs. dmarc X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Dec 2020 16:22:21 -0000 --00000000000039870705b7b0e969 Content-Type: text/plain; charset="UTF-8" On Wed, Dec 30, 2020 at 10:41 AM Michael Thomas wrote: > > On 12/30/20 7:35 AM, Todd Herr wrote: > > On Wed, Dec 30, 2020 at 9:01 AM Michael Thomas wrote: > >> >> On 12/30/20 5:48 AM, Todd Herr wrote: >> >> >> I propose to add two new result name codes, named after the policy >>> requests: >>> >>> dmarc=quarantine, and >>> >>> dmarc=reject (of course, you only see this if the filter didn't >>> honor the request). >>> >>> >> I do not support this, because quarantine, reject, and none are not >> Authentication Results, but are instead both policy requests and >> disposition decisions. >> >> Then we should remove DMARC from auth-res altogether because it is not an >> authentication mechanism. Either we fully support DMARC in auth-res or >> remove it. This half-assed state of unlessness serves nobody. >> >> >> I disagree. DMARC has rules that determine whether or not a message is > deemed to be authenticated - did it pass SPF or DKIM and did it do so with > a domain that aligns with the RFC5322.From domain. The currently valid > states for those rules are pass, fail, temperror, and permerror. > > Policy and disposition (none, quarantine, reject) apply to decisions made > based on the authentication results; they are not states for the > authentication checks themselves. > > DMARC != Auth-res. Auth-res provides all kinds of useful information than > just pass/fail. For DMARC Auth-res should provide what the policy was at a > bare minimum. But none of this seems to have any normative language > anywhere which is a problem unto itself. DMARC in auth-res seems to be an > orphan. > > Mike > You just stated the case as to why this discussion should be ruled out of scope. " DMARC != Auth-res." and " DMARC in auth-res seems to be an orphan" This is the IETF DMARC working group, not the AUTH-RES working group. You gave the example of someone writing a crappy Thunderbird extension as a reason for the working group to change its focus. Perhaps getting the extension author to fix their extension might be a more fruitful effort. Michael Hammer --00000000000039870705b7b0e969 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Dec 30, 2020 at 10:41 AM Mich= ael Thomas <mike@mtcc.com> wrote= :
=20 =20 =20


On 12/30/20 7:35 AM, Todd Herr wrote:
=20
On Wed, Dec 30, 2020 at 9:01 AM Michael Thomas <mike@mtcc.= com> wrote:


On 12/30/20 5:48 AM, Todd Herr wrote:

I pr= opose to add two new result name codes, named after the policy requests:

=C2=A0 =C2=A0 dmarc=3Dquarantine, and

=C2=A0 =C2=A0 dmarc=3Dreject (of course, you only see= this if the filter didn't honor the request).


I do not support this, because quarantine, reject, and none are not Authentication Results, but are instead both policy requests and disposition decisions.=C2=A0

Then we should remove DMARC from auth-res altogether because it is not an authentication mechanism. Either we fully support DMARC in auth-res or remove it. This half-assed state of unlessness serves nobody.


I disagree. DMARC has rules that determine whether or not a message is deemed to be authenticated - did it pass SPF or DKIM and did it do so with a domain that aligns with the RFC5322.From domain. The currently valid states for those rules are pass, fail, temperror, and permerror.

Policy and disposition (none, quarantine, reject) apply to decisions made based on the authentication results; they are not states for the authentication checks themselves.=C2=A0<= /div>

DMARC !=3D Auth-res. Auth-res provides all kinds of useful information than just pass/fail. For DMARC Auth-res should provide what the policy was at a bare minimum. But none of this seems to have any normative language anywhere which is a problem unto itself. DMARC in auth-res seems to be an orphan.

Mike


You just stated the c= ase as to why this discussion should be ruled out of scope.=C2=A0 " DMARC !=3D Auth-res." and " DMARC in auth-res seems to be an orphan"

This= is the IETF DMARC working group, not the AUTH-RES working group. You gave = the example of someone writing a crappy Thunderbird extension as a reason f= or the working group to change its focus. Perhaps getting the extension aut= hor to fix their extension might be a more fruitful effort.
=
Michael Hammer
--00000000000039870705b7b0e969-- From nobody Wed Dec 30 08:30: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 08FC93A0962 for ; Wed, 30 Dec 2020 08:30:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, 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=mtcc.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 2jfGRerXh67q for ; Wed, 30 Dec 2020 08:30:49 -0800 (PST) Received: from mail-pj1-x1033.google.com (mail-pj1-x1033.google.com [IPv6:2607:f8b0:4864:20::1033]) (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 B8CFE3A0957 for ; Wed, 30 Dec 2020 08:30:49 -0800 (PST) Received: by mail-pj1-x1033.google.com with SMTP id n3so2190212pjm.1 for ; Wed, 30 Dec 2020 08:30:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mtcc.com; s=fluffulence; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=67XMxI+luqzJnDREynqYKLRRuekXzB8ysopZNXB7zXw=; b=jW63y28mEywqz2C4WWxyxWWVVtJrs9ERLa/tAig0dkgIo7ZZLk5ODHmSCOurqovBnh 0mEXOdWgo3aPGdpD3t123NMiuKLYjKHr72qVHne5WFuTLjHjTh0sepPKcCz6M2smjzek idzaSd+8wCuo/PRvyeZfV+F+mekqO9Z3Pf4BFVJyx5ntIEJyHjpi6E+skG+LJyN+DQdh mhQcaeUsH7QeAhxACs4QBg/gPC39JdwpFNo6uXW/FQajer/VtyWXwVIk5Xf3CeMpTiw1 tn1wIuUgns+NMVBncQOAZ8XQbAt83CqQMyxDbRfQ8GKS3lKd1v5lFql82Kh+bch31iKj cefg== 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=67XMxI+luqzJnDREynqYKLRRuekXzB8ysopZNXB7zXw=; b=Z9uIti+Om1Iy+osV0rgFC78NCqfqNxHYAjel7FrZhfy0azFwM2rAYxkqczCXwHJib1 c4FGkvLEHAw0jTkCqJSg7jMLiPRUf9o0+S/SHpzaHsYkbehJrkGTYAsVD0HNx/z6H+5V aRCJ6am8a8o5jKUV7EVB2IqgLp0hq+h4JoDAGpZiUL6AB7TLGL2wyCA0Dx904ApQ0+v+ OVSNgdiKUFlIJbY3So7kbV986pLN1Z1kYwxI1RJU37Qs7/Kx3LUZ7jgyXWOVSEDpvHi6 xSWOkf88ZuuIrQaRdDDjmP5ivvIQQumJ1Lf9r1eiJjwwAe6kD1XqH3CXDiterkeHnKXN 5uuw== X-Gm-Message-State: AOAM533fgnWrXXcIKA/SKg3pCf5n8Nsqnc3lkFErr4c/SvtKYThu415I m46mCQWAoLNxFKmlzE8I2/3nhzXl9Y8Zeg== X-Google-Smtp-Source: ABdhPJzLBoxl53q3BvJmxWXt6mlKmIPC13Iu7LdIGFpD72h+Ec2vbVqDlkjwG8+XoEvh5f44HQdnDQ== X-Received: by 2002:a17:902:fe07:b029:dc:43e4:fcbf with SMTP id g7-20020a170902fe07b02900dc43e4fcbfmr30724884plj.63.1609345848741; Wed, 30 Dec 2020 08:30:48 -0800 (PST) Received: from mike-mac.lan (107-182-45-95.volcanocom.com. [107.182.45.95]) by smtp.gmail.com with ESMTPSA id y27sm44458527pfr.78.2020.12.30.08.30.47 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 30 Dec 2020 08:30:47 -0800 (PST) To: Dotzero Cc: IETF DMARC WG References: <9f6782b1-e85b-1a9c-9151-98feff7e18ea@mtcc.com> <140485eb-020f-4406-3f2f-e2c475ea51e5@mtcc.com> <5588dbbe-b876-ed80-c80f-792380e3718f@mtcc.com> <54dd9978-bcd1-6757-ad27-dcef6db6e5f7@mtcc.com> <937f1019-a028-308d-2a0f-1e720fd49dcd@mtcc.com> <72e20c17-e991-e82a-9120-a27097e3ac58@mtcc.com> <7863d250-f56a-1fe1-44ee-fbc7486d48b4@mtcc.com> From: Michael Thomas Message-ID: <502c2363-385c-b90c-a22a-716594967190@mtcc.com> Date: Wed, 30 Dec 2020 08:30:46 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------5629053CECE81519042826D9" Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] auth-res vs. dmarc X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Dec 2020 16:30:51 -0000 This is a multi-part message in MIME format. --------------5629053CECE81519042826D9 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 12/30/20 8:22 AM, Dotzero wrote: > > DMARC != Auth-res. Auth-res provides all kinds of useful > information than just pass/fail. For DMARC Auth-res should provide > what the policy was at a bare minimum. But none of this seems to > have any normative language anywhere which is a problem unto > itself. DMARC in auth-res seems to be an orphan. > > Mike > > > You just stated the case as to why this discussion should be ruled out > of scope.  " DMARC != Auth-res." and " DMARC in auth-res seems to be > an orphan" > > This is the IETF DMARC working group, not the AUTH-RES working group. > You gave the example of someone writing a crappy Thunderbird extension > as a reason for the working group to change its focus. Perhaps getting > the extension author to fix their extension might be a more fruitful > effort. > Because the author *can't* fix their extension for the 100th time. There is no normative mechanism for transporting the DMARC state in the auth-res header. And if the working group is not willing to do its part for auth res, then auth-res should just be moved to historic since there is nobody to maintain it, and no place to discuss its shortcomings. Requiring every downstream MTA and MUA to do DMARC policy checks would be a mess and *that* is most certainly in scope as scaling is an internet issue. Mike --------------5629053CECE81519042826D9 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit


On 12/30/20 8:22 AM, Dotzero wrote:

DMARC != Auth-res. Auth-res provides all kinds of useful information than just pass/fail. For DMARC Auth-res should provide what the policy was at a bare minimum. But none of this seems to have any normative language anywhere which is a problem unto itself. DMARC in auth-res seems to be an orphan.

Mike


You just stated the case as to why this discussion should be ruled out of scope.  " DMARC != Auth-res." and " DMARC in auth-res seems to be an orphan"

This is the IETF DMARC working group, not the AUTH-RES working group. You gave the example of someone writing a crappy Thunderbird extension as a reason for the working group to change its focus. Perhaps getting the extension author to fix their extension might be a more fruitful effort.


Because the author *can't* fix their extension for the 100th time. There is no normative mechanism for transporting the DMARC state in the auth-res header. And if the working group is not willing to do its part for auth res, then auth-res should just be moved to historic since there is nobody to maintain it, and no place to discuss its shortcomings. Requiring every downstream MTA and MUA to do DMARC policy checks would be a mess and *that* is most certainly in scope as scaling is an internet issue.

Mike

--------------5629053CECE81519042826D9-- From nobody Wed Dec 30 08:38: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 F23A93A098D for ; Wed, 30 Dec 2020 08:38:43 -0800 (PST) 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 kfR4DSiHL9I8 for ; Wed, 30 Dec 2020 08:38:42 -0800 (PST) Received: from mail-qk1-x72e.google.com (mail-qk1-x72e.google.com [IPv6:2607:f8b0:4864:20::72e]) (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 83BB13A098A for ; Wed, 30 Dec 2020 08:38:42 -0800 (PST) Received: by mail-qk1-x72e.google.com with SMTP id n142so14332167qkn.2 for ; Wed, 30 Dec 2020 08:38:42 -0800 (PST) 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=wriJpAtRFRwjVLeIygosJbHO7R1d34iRGw1lc2ao31w=; b=e274kmMkdrHVv8XJ6qG3WMK85F0voSPKwZeofnqTwWPDd+CfWXs5r/vvx3H51CGGVi 0oN2i6IzpomfQThIHQjRZK1tmlujSi0lNwix+GmiC+t3wsRnBlAtMZJwYCjubXw4Aao9 Z78Ck+x5pCeD5OkRQAdKivkX+MTk3aI8ug4t7WR4MSCBIHkwXdG91fdjXto8fFAs5UmX oTRdHRPqUXwabs9Ho0v61dYhHin2K9RJ5vNBCd6RLMh3BGM4XuH4ucKRAnbOXHt/g3U5 1SebyhuzMuUIDdAEff8/hHQ0jFtEwKEg1g+gHIqPVNzrGxi89If5cR4Qz1+VyJxlb9NY CKyw== 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=wriJpAtRFRwjVLeIygosJbHO7R1d34iRGw1lc2ao31w=; b=D0LWQB1lEvZ0avv/n6nH8fAu9kERMC795dChAPr7JUb1RkwuMj8t2MJbEQgx4xLl9B Chnbdibo+UyXZ6p30/FeBZ95/0YXsRPGNaPC64hVYpaQLKYP4zREy6eA0FmWDRSmZk5e Vd3E3yw97Kg7X89KEwiYW+HWOr2qWzQ9h0XQ/ujG8mvRF7B2GPWaXQeNRNfOhBraJIZl cKCLhGFAQlXs/NUFID4CrGTY6YgBZgeVstayUYdrR4n6LI3dbe698gLvVNt276abG2L2 F8QN2KAp3qUbYnLbxSohoRUNuIUE/IsP0EbChnW44Nr03SnwRlBcb6ili26mcXXphQBA jLug== X-Gm-Message-State: AOAM531spN0AfaoAYLmkCoCF8/bMNofiI9CPQPW+c0oS9FhQdLha6BFB IP0rErFD2j8tZ7AtmRDrMnDFjvcpZGVY5eCecHg= X-Google-Smtp-Source: ABdhPJyjxM0XoGNch0oW0yjt4gIqL0zOxc/PFvmCEpmb0QDKFIkBRIKMUoGLbT2xQMTnLeHxYugYXSeLkeANPLWfhZM= X-Received: by 2002:a05:620a:f92:: with SMTP id b18mr53977008qkn.146.1609346321320; Wed, 30 Dec 2020 08:38:41 -0800 (PST) MIME-Version: 1.0 References: <9f6782b1-e85b-1a9c-9151-98feff7e18ea@mtcc.com> <140485eb-020f-4406-3f2f-e2c475ea51e5@mtcc.com> <5588dbbe-b876-ed80-c80f-792380e3718f@mtcc.com> <54dd9978-bcd1-6757-ad27-dcef6db6e5f7@mtcc.com> <937f1019-a028-308d-2a0f-1e720fd49dcd@mtcc.com> <72e20c17-e991-e82a-9120-a27097e3ac58@mtcc.com> <7863d250-f56a-1fe1-44ee-fbc7486d48b4@mtcc.com> <502c2363-385c-b90c-a22a-716594967190@mtcc.com> In-Reply-To: <502c2363-385c-b90c-a22a-716594967190@mtcc.com> From: Dotzero Date: Wed, 30 Dec 2020 11:38:29 -0500 Message-ID: To: Michael Thomas Cc: IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000cd8f0a05b7b1234c" Archived-At: Subject: Re: [dmarc-ietf] auth-res vs. dmarc X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Dec 2020 16:38:44 -0000 --000000000000cd8f0a05b7b1234c Content-Type: text/plain; charset="UTF-8" On Wed, Dec 30, 2020 at 11:30 AM Michael Thomas wrote: > > On 12/30/20 8:22 AM, Dotzero wrote: > > > DMARC != Auth-res. Auth-res provides all kinds of useful information than >> just pass/fail. For DMARC Auth-res should provide what the policy was at a >> bare minimum. But none of this seems to have any normative language >> anywhere which is a problem unto itself. DMARC in auth-res seems to be an >> orphan. >> >> Mike >> > > You just stated the case as to why this discussion should be ruled out of > scope. " DMARC != Auth-res." and " DMARC in auth-res seems to be an orphan" > > This is the IETF DMARC working group, not the AUTH-RES working group. You > gave the example of someone writing a crappy Thunderbird extension as a > reason for the working group to change its focus. Perhaps getting the > extension author to fix their extension might be a more fruitful effort. > > > Because the author *can't* fix their extension for the 100th time. There > is no normative mechanism for transporting the DMARC state in the auth-res > header. And if the working group is not willing to do its part for auth > res, then auth-res should just be moved to historic since there is nobody > to maintain it, and no place to discuss its shortcomings. Requiring every > downstream MTA and MUA to do DMARC policy checks would be a mess and *that* > is most certainly in scope as scaling is an internet issue. > > Mike > And for the second time, that is not a DMARC problem, it is an auth-res problem. It is also a problem for someone who writes an extension without understanding what they are presenting to the end user. Michael Hammer --000000000000cd8f0a05b7b1234c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Dec 30, 2020 at 11:30 AM Mich= ael Thomas <mike@mtcc.com> wrote= :
=20 =20 =20


On 12/30/20 8:22 AM, Dotzero wrote:
=20

DMARC !=3D Auth-res. Auth-res provides all kinds of useful information than just pass/fail. For DMARC Auth-res should provide what the policy was at a bare minimum. But none of this seems to have any normative language anywhere which is a problem unto itself. DMARC in auth-res seems to be an orphan.

Mike


You just stated the case as to why this discussion should be ruled out of scope.=C2=A0 " DMARC !=3D Auth-res." and " DMARC in auth-res seems to be an orphan"

This is the IETF DMARC working group, not the AUTH-RES working group. You gave the example of someone writing a crappy Thunderbird extension as a reason for the working group to change its focus. Perhaps getting the extension author to fix their extension might be a more fruitful effort.


Because the author *can't* fix their extension for the 100th time. There is no normative mechanism for transporting the DMARC state in the auth-res header. And if the working group is not willing to do its part for auth res, then auth-res should just be moved to historic since there is nobody to maintain it, and no place to discuss its shortcomings. Requiring every downstream MTA and MUA to do DMARC policy checks would be a mess and *that* is most certainly in scope as scaling is an internet issue.

Mike


And for the secon= d time, that is not a DMARC problem, it is an auth-res problem. It is also = a problem for someone who writes an extension without understanding what th= ey are presenting to the end user.

Michael Ham= mer
--000000000000cd8f0a05b7b1234c-- From nobody Wed Dec 30 08:38: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 642FE3A09A4 for ; Wed, 30 Dec 2020 08:38:48 -0800 (PST) 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 P5JwHMlVrqP9 for ; Wed, 30 Dec 2020 08:38:45 -0800 (PST) Received: from mail-qk1-x72e.google.com (mail-qk1-x72e.google.com [IPv6:2607:f8b0:4864:20::72e]) (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 B4DDC3A098A for ; Wed, 30 Dec 2020 08:38:45 -0800 (PST) Received: by mail-qk1-x72e.google.com with SMTP id 186so14344008qkj.3 for ; Wed, 30 Dec 2020 08:38:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=u79dmb5XAJqRxsQCn2Tg+qfAoW5cwwCcfc3Rmlo0ogI=; b=fK1PCS+l+8DTKvpA78dVToJctZF6SFTJPOGUVsykLsgyrg23/0qIgfmragNBqrP8IG ZQog7wOQtlCf3fcjNzpGbjRsU1zrLUJg/MuB+ZlztSDFRVCIrSfH82oNOkFxt4uBnLdg aQiioVnER+45yjiCEjt8Ab2lsQdDualCQROWA5SjdwYdl3cA1dhWip885mAqZzEJZh49 2ceY1tz9yhbxis/boGKr8n3rFzZtLDdxz1STFEP6thYlyR42IEbnMEAH5rWwPHCkADoQ zrSQUJM6fs5wDMD6Fh+yF83myc4f0mgfNMIE8SxfrRjw2fHYH05LgL8OfR+yu5nrkGAE oAig== 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=u79dmb5XAJqRxsQCn2Tg+qfAoW5cwwCcfc3Rmlo0ogI=; b=XUlrO+DT6Cx1YPUw39d34emqQjSav5ByGYXULCxeH9MMolJW5uNCkSUEGcP7ghoneR bFBRz5u/DuY3sIg5snBPdqgUrpk5p8QEe8JEhxr2rzBkvEpoZUKhygygR/Q7sm0roGPQ LNASThLtyj26o3rZZkvtkpJuRynvzcqmxp+MmKkqa2+pkwcIoWj4m24SDhsDOL2B2nAV LWJk3blvCVBiVfQ5O4y3RU7SrjrHme9T8LKBkeGFqSmrJDoG2Ro30gE73URQ+65y06Se HuTMPxqiE3LTpCGTLttm1+R2FjRJtpQWIZLsYjZNiog5TuiQeWL3ni9f1T1Gye/iM3ff XC8Q== X-Gm-Message-State: AOAM533YDCJQGjN+/f0q+PD+qygvrtRYyz3kGOQNWfyqiCX3tMA2jbzQ yriOwBAB5Z9okV16orDOgAmE7HtdIoAoA8ofbhbf8+bTS3rM2w== X-Google-Smtp-Source: ABdhPJyasoHnBlT9iC1ru4eTJKp8L2mnJqJG7Ne6cvrvuG24Zzhv0oFtnD0pwhyijeuUSzb8JimDLDAR1XLJ7Ou5hxg= X-Received: by 2002:a37:e20d:: with SMTP id g13mr54913992qki.325.1609346324382; Wed, 30 Dec 2020 08:38:44 -0800 (PST) MIME-Version: 1.0 References: <9f6782b1-e85b-1a9c-9151-98feff7e18ea@mtcc.com> <140485eb-020f-4406-3f2f-e2c475ea51e5@mtcc.com> <5588dbbe-b876-ed80-c80f-792380e3718f@mtcc.com> <54dd9978-bcd1-6757-ad27-dcef6db6e5f7@mtcc.com> <937f1019-a028-308d-2a0f-1e720fd49dcd@mtcc.com> <9c5f18c2-c5f6-4f66-a185-f684949738b5@mtcc.com> <326d993e-0d92-206b-dd94-bef21ddfbaaa@mtcc.com> <06474cf1-105a-b6fb-a7b5-de6f7dff761d@mtcc.com> In-Reply-To: <06474cf1-105a-b6fb-a7b5-de6f7dff761d@mtcc.com> From: Todd Herr Date: Wed, 30 Dec 2020 11:38:28 -0500 Message-ID: To: IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000fc5b5f05b7b123e4" Archived-At: Subject: Re: [dmarc-ietf] auth-res vs. dmarc X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Dec 2020 16:38:54 -0000 --000000000000fc5b5f05b7b123e4 Content-Type: text/plain; charset="UTF-8" On Wed, Dec 30, 2020 at 10:48 AM Michael Thomas wrote: > > On 12/30/20 7:40 AM, Todd Herr wrote: > > I already said there is a thunderbird extension called dkim-verify that > does exactly that. It says "DMARC: fail". That is highly misleading to the > user. > >> >> I see. > > I wrote "MDAs and local clients (web and mobile) at the mailbox > provider", and I was referring to things such as Gmail's web client, > Gmail's mobile client, etc. > > You are talking about an extension for Thunderbird, which is different > from what I'm talking about. > > Thank you for the clarification. > > This would be a problem for any MUA. That's the point. It's not different, > it's the exact same problem for every MUA. There is no normative mechanism > that gives anything downstream from the DMARC check producing the auth-res > to be able to use that information correctly. And we sure don't want > billions of MUA's doing DMARC checks on their own because of the inadequacy > of auth-res. There is code in that extension to do exactly that. If that > were widespread, it would be disastrous. > > > As I attempted to communicate in a different message, we're making assumptions about the use of the A-R header that may not be entirely valid. RFC 8601 says in its Abstract: Any receiver-side software, such as mail filters or Mail User Agents (MUAs), can use this header field to relay that information in a convenient and meaningful way to users or to make sorting and filtering decisions. It does not say, however, "can use this header field, AND ONLY THIS HEADER FIELD, to relay that information"; it doesn't even require that the header be included. There are quite a number of headers inserted into messages at the major mailbox providers, and I'd wager that some of them are used by the MDAs and local clients instead of the A-R header when executing their message delivery and display actions; I might be wrong, but I imagine the folks who've put together these enormous email systems do things in such a way that maximizes efficiency for them. -- *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. --000000000000fc5b5f05b7b123e4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Dec 30, 2020 at 10:48 AM Michael = Thomas <mike@mtcc.com> wrote:
=20 =20 =20


On 12/30/20 7:40 AM, Todd Herr wrote:
=20
I already said there is a thunderbird extension called dkim-verify that does exactly that. It says "DMARC: fail". That is highly misleading to the user.


I see.=C2=A0

I wrote "MDAs and local clients (web and mobile) at the mailbox provider",=C2=A0 and I was referring to things suc= h as Gmail's web client, Gmail's=C2=A0mobile client, etc.=C2= =A0

You are talking about an extension for Thunderbird, which is different from what I'm talking about.=C2=A0

Thank you for the clarification.

This would be a problem for any MUA. That's the point. It's = not different, it's the exact same problem for every MUA. There is no normative mechanism that gives anything downstream from the DMARC check producing the auth-res to be able to use that information correctly. And we sure don't want billions of MUA's doing DMA= RC checks on their own because of the inadequacy of auth-res. There is code in that extension to do exactly that. If that were widespread, it would be disastrous.



As I attempted to com= municate in a different message, we're making assumptions about the use= of the A-R header that may not be entirely valid. RFC 8601 says in its Abs= tract:

   Any receiver-side software, such as=
 mail filters or Mail User Agents
   (MUAs), can use this header field to relay that information in a
   convenient and meaningful way to users or to make sorting and=C2=A0filte=
ring decisions.

It does not say, however, "ca= n use this header field, AND ONLY THIS HEADER FIELD, to relay that informat= ion"; it doesn't even require that the header be included.=C2=A0

There are quite a number of headers inserted into m= essages at the major mailbox providers, and I'd wager that some of them= are used by the MDAs and local clients instead of the A-R header when exec= uting their message delivery and display actions; I might be wrong, but I i= magine the folks who've put together these enormous email systems do th= ings in such a way that maximizes efficiency for them.

=
--

Todd Herr | Sr. Technical Program Manager
= e: todd.herr@valimail.com
p: 703.220.4153


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

--000000000000fc5b5f05b7b123e4-- From nobody Wed Dec 30 08:39: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 EAC863A0AB4 for ; Wed, 30 Dec 2020 08:38:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, 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=mtcc.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 sW5M_fSANd2P for ; Wed, 30 Dec 2020 08:38:55 -0800 (PST) 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 9B44C3A0AA0 for ; Wed, 30 Dec 2020 08:38:55 -0800 (PST) Received: by mail-pg1-x52d.google.com with SMTP id v19so11607991pgj.12 for ; Wed, 30 Dec 2020 08:38:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mtcc.com; s=fluffulence; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=ifIZAzNVT2B/i9XTJQsPRk+PU/9ItfXMKgm1r/uxjLc=; b=horA+I3jrfUNNmkKjI1iTQ/GmABXsuSyc4rHaSaJpJXoN5nuDM5V0SzadWY0Y8jqpU FOJaD2hP91/HHfrVtI+IQ2IgBGywsJW4HNCs/sEr0ij4u4oD3p1tjWUMsAFUOSIrCslV NBoxpZiZ7q7f/CfE4VE8QFcsf0+h3MfVeNN3jsiMzmRY+RZr5VwffLJ2jmcOCh1aVkxC AcdHPNIIS8Eh5g6tHum61ZGo6bUqXd08kos8p8Cpwb0wNMWie20RVWuP4/NK90XLQSl8 P92nzIF+QFayW6O4HwXeJXL1gGjHzPPoQnSXuP7yz3KKsqMfxhbIHlYotSzjG/idijgs Ec/w== 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=ifIZAzNVT2B/i9XTJQsPRk+PU/9ItfXMKgm1r/uxjLc=; b=HniVsPTVknlseFreRIKMBJVhfbikfxzL0GDLMNNVqIiP6caRRgMV8VeeyoVhNpYPX0 IUlStc1jUTdbyPfyyzu9pdW+GJTMAS+XU0pcjYXsKhxZPO8eRMH3wl54vH1tgwg6SyKB yEuv9EpFv5nFo+T0IcIsbJ0Mkso6TWkIoptWDkEXz9H6KDJso2wwi/UCP8aB79U3krJo vyNRC6ogrfMNRI25jRUMJumVuhaRR4bg3b6H9kE3T1vIH7shJC2wiSji6g8Xoidun2X7 IfHtNUweXM7qmDacj7j3RqN4oM0+YZ9Ep0fIvuPDnqHs6b7y+JJ/yRJoDSYUeiSyC7Tq YDsA== X-Gm-Message-State: AOAM530WatPKI8XDfqOY/nj7qY5RwFnfc4Qmqpq107/QUf9sutAZ8xdP kgYqB6lWlq7P+ug82zpIu7tbuWKTHHMuXQ== X-Google-Smtp-Source: ABdhPJzdaHTd+1SBbTo0W6LcCDwK/iB1VfJrZGws06cjtKGkLUqDKlkwccAx7ibZ3ZfIfjvw3vrcRw== X-Received: by 2002:a05:6a00:885:b029:19b:9057:16f with SMTP id q5-20020a056a000885b029019b9057016fmr49019031pfj.80.1609346334568; Wed, 30 Dec 2020 08:38:54 -0800 (PST) Received: from mike-mac.lan (107-182-45-95.volcanocom.com. [107.182.45.95]) by smtp.gmail.com with ESMTPSA id u14sm40223061pfk.111.2020.12.30.08.38.53 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 30 Dec 2020 08:38:53 -0800 (PST) To: Dotzero Cc: IETF DMARC WG References: <9f6782b1-e85b-1a9c-9151-98feff7e18ea@mtcc.com> <140485eb-020f-4406-3f2f-e2c475ea51e5@mtcc.com> <5588dbbe-b876-ed80-c80f-792380e3718f@mtcc.com> <54dd9978-bcd1-6757-ad27-dcef6db6e5f7@mtcc.com> <937f1019-a028-308d-2a0f-1e720fd49dcd@mtcc.com> <72e20c17-e991-e82a-9120-a27097e3ac58@mtcc.com> <7863d250-f56a-1fe1-44ee-fbc7486d48b4@mtcc.com> From: Michael Thomas Message-ID: Date: Wed, 30 Dec 2020 08:38:52 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------84F4B323B8D1E2E08EBA74BB" Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] auth-res vs. dmarc X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Dec 2020 16:39:03 -0000 This is a multi-part message in MIME format. --------------84F4B323B8D1E2E08EBA74BB Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 12/30/20 8:22 AM, Dotzero wrote: > > You just stated the case as to why this discussion should be ruled out > of scope.  " DMARC != Auth-res." and " DMARC in auth-res seems to be > an orphan" > > This is the IETF DMARC working group, not the AUTH-RES working group. > You gave the example of someone writing a crappy Thunderbird extension > as a reason for the working group to change its focus. Perhaps getting > the extension author to fix their extension might be a more fruitful > effort. > Let me put this another way: "The verifying DMARC SHOULD encode its results into an Authentication-Results header [RFC 8601] for downstream MTA's, MDA's, and MUA in the same administrative domain, and those downstream entities SHOULD use the Authentication-Results so as to not put undue burden on the DNS infrastructure". Anything that would cause them to have to violate that SHOULD is a problem that needs to be resolved. Mike, getting tired of the circularity going on here --------------84F4B323B8D1E2E08EBA74BB Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit


On 12/30/20 8:22 AM, Dotzero wrote:

You just stated the case as to why this discussion should be ruled out of scope.  " DMARC != Auth-res." and " DMARC in auth-res seems to be an orphan"

This is the IETF DMARC working group, not the AUTH-RES working group. You gave the example of someone writing a crappy Thunderbird extension as a reason for the working group to change its focus. Perhaps getting the extension author to fix their extension might be a more fruitful effort.


Let me put this another way:

"The verifying DMARC SHOULD encode its results into an Authentication-Results header [RFC 8601] for downstream MTA's, MDA's, and MUA in the same administrative domain, and those downstream entities SHOULD use the Authentication-Results so as to not put undue burden on the DNS infrastructure".

Anything that would cause them to have to violate that SHOULD is a problem that needs to be resolved.

Mike, getting tired of the circularity going on here

--------------84F4B323B8D1E2E08EBA74BB-- From nobody Wed Dec 30 08:42: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 39A313A0992 for ; Wed, 30 Dec 2020 08:42:20 -0800 (PST) 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 N6hW1DhqBjq0 for ; Wed, 30 Dec 2020 08:42:18 -0800 (PST) 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 30BE23A0990 for ; Wed, 30 Dec 2020 08:42:18 -0800 (PST) Received: by mail-vs1-xe2c.google.com with SMTP id x26so8851703vsq.1 for ; Wed, 30 Dec 2020 08:42:18 -0800 (PST) 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=beKvzgLBPimTg3oih9RO9pPmE0DJwqFEZPLG/T7v5/0=; b=Al0LRgQifxcX3l0Rnb0Q37RZMR9izo1B/ztZ4JDD9UiYUPEUFX/X2WpOln4nTTGroT w+7WhMmBnetxjKAZgdITfP+zx/HbhPxc2HlakcK5c01/8GOVkiaZ8Wi9Ub5JIlF/fY9t GKziQUVt2QidC6di4wEVP4o5SWDJoCp6YyPRQaoFKt3yW46hL2LJh+XyXsZORYDhe8k5 eoKrllB+z1fwISZw2pvVg43m/VOFepgQKiaGPHR69ZwcderpMyjG4tk7UUwoJQVDM50y FeY3NnCyRSDX7i8DKkW0GDcxrcoTlkf+AsZivs0a50Fh7OQa/uSn00QQF4NIXdxRGdGl 3ftQ== 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=beKvzgLBPimTg3oih9RO9pPmE0DJwqFEZPLG/T7v5/0=; b=UBHX4aafp4ukVHpvwjFB6DGznZMn8B6HkRFZlKaysGPY3sC34P7ZpBBy/2XjdKl68r ZRZcn6+yhOc/FRiR8a6VR7+ezxndmyfbhkaakuXodp2wR4oTJT0sxO/aUv4lMIAceB6h jp3ICQUOk+ku+jBonTp9LhzSsNYmOz4+bwSl7yKuYvNZsNExBbdIxwo7iPdMFgLHAFs5 yL4JwmzLKMgEHB1c0eg3p/VPwU/8SNKzNChlp2XAf2F7XfaVfy3mrlod0Me3tCl3WRLF uVeHkjUzQlV6bWn2Vd0st80p3JtBuII7HHx7xaZj9KRfVeSbKm5Hl3Wg5GGfVaYGBwOQ kflw== X-Gm-Message-State: AOAM533locxNclFQeiVjCsudBkktyktiISGflHq1YcmuZ3I3o3E+Q25P Vsf965HK71I7/1wT23rGttZwHw9Zg5GrzGEt/4yRIA== X-Google-Smtp-Source: ABdhPJyg1qzvjAiH3he3nkTAu1jnnNdIiRhrbnLzm0sh6WzAqpv8rV2YN2Hyg1fIMXqkXIW7lWOXESUGSkqk4r64b3s= X-Received: by 2002:a67:efd9:: with SMTP id s25mr32975435vsp.56.1609346537013; Wed, 30 Dec 2020 08:42:17 -0800 (PST) MIME-Version: 1.0 References: <9f6782b1-e85b-1a9c-9151-98feff7e18ea@mtcc.com> <140485eb-020f-4406-3f2f-e2c475ea51e5@mtcc.com> <5588dbbe-b876-ed80-c80f-792380e3718f@mtcc.com> <54dd9978-bcd1-6757-ad27-dcef6db6e5f7@mtcc.com> <937f1019-a028-308d-2a0f-1e720fd49dcd@mtcc.com> <72e20c17-e991-e82a-9120-a27097e3ac58@mtcc.com> <7863d250-f56a-1fe1-44ee-fbc7486d48b4@mtcc.com> In-Reply-To: From: Seth Blank Date: Wed, 30 Dec 2020 08:42:06 -0800 Message-ID: To: Michael Thomas Cc: Dotzero , IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000a8d5a805b7b130fb" Archived-At: Subject: Re: [dmarc-ietf] auth-res vs. dmarc X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Dec 2020 16:42:20 -0000 --000000000000a8d5a805b7b130fb Content-Type: text/plain; charset="UTF-8" At this point, this thread is deeply unproductive and preventing work on open tickets. Mike, I hear that you believe better normative accounting for DMARC results in auth-res is needed. If this is correct, please open a ticket, and the working group will address it later as we've committed to discussing all open tickets. Seth, as Chair On Wed, Dec 30, 2020 at 8:39 AM Michael Thomas wrote: > > On 12/30/20 8:22 AM, Dotzero wrote: > > > You just stated the case as to why this discussion should be ruled out of > scope. " DMARC != Auth-res." and " DMARC in auth-res seems to be an orphan" > > This is the IETF DMARC working group, not the AUTH-RES working group. You > gave the example of someone writing a crappy Thunderbird extension as a > reason for the working group to change its focus. Perhaps getting the > extension author to fix their extension might be a more fruitful effort. > > > Let me put this another way: > > "The verifying DMARC SHOULD encode its results into an > Authentication-Results header [RFC 8601] for downstream MTA's, MDA's, and > MUA in the same administrative domain, and those downstream entities SHOULD > use the Authentication-Results so as to not put undue burden on the DNS > infrastructure". > > Anything that would cause them to have to violate that SHOULD is a problem > that needs to be resolved. > > Mike, getting tired of the circularity going on here > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > -- *Seth Blank* | VP, Standards and New Technologies *e:* seth@valimail.com *p:* 415.273.8818 This email and all data transmitted with it contains confidential and/or proprietary information intended solely for the use of individual(s) authorized to receive it. If you are not an intended and authorized recipient you are hereby notified of any use, disclosure, copying or distribution of the information included in this transmission is prohibited and may be unlawful. Please immediately notify the sender by replying to this email and then delete it from your system. --000000000000a8d5a805b7b130fb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
At this point, this thread is deeply unproductive and prev= enting work on open tickets.

Mike, I hear that you b= elieve better normative accounting for DMARC results in auth-res is needed.= If this is correct, please open a ticket, and the working group will addre= ss it later as we've committed to discussing all open tickets.

Seth, as Chair

<= div dir=3D"ltr" class=3D"gmail_attr">On Wed, Dec 30, 2020 at 8:39 AM Michae= l Thomas <mike@mtcc.com> wrote:<= br>
=20 =20 =20


On 12/30/20 8:22 AM, Dotzero wrote:
=20

You just stated the case as to why this discussion should be ruled out of scope.=C2=A0 " DMARC !=3D Auth-res." and " DMARC in auth-res seems to be an orphan"

This is the IETF DMARC working group, not the AUTH-RES working group. You gave the example of someone writing a crappy Thunderbird extension as a reason for the working group to change its focus. Perhaps getting the extension author to fix their extension might be a more fruitful effort.


Let me put this another way:

"The verifying DMARC SHOULD encode its results into an Authentication-Results header [RFC 8601] for downstream MTA's, MDA's, and MUA in the same administrative domain, and those downstream entities SHOULD use the Authentication-Results so as to not put undue burden on the DNS infrastructure".

Anything that would cause them to have to violate that SHOULD is a problem that needs to be resolved.

Mike, getting tired of the circularity going on here

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


--

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


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

--000000000000a8d5a805b7b130fb-- From nobody Wed Dec 30 09:12: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 21CDE3A0A3B for ; Wed, 30 Dec 2020 09:12:35 -0800 (PST) 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=GHq01HIM; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=k0yAhU4H Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wFDh9Fj--gzU for ; Wed, 30 Dec 2020 09:12:32 -0800 (PST) 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 984113A0A1E for ; Wed, 30 Dec 2020 09:12:31 -0800 (PST) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha256; c=simple/relaxed; l=4130; t=1609348342; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=Xxlw9E0RVIUDtaE798+SXzg9f1A7 P2Tx4QlnrCMN94A=; b=GHq01HIMNdmDYZ8oXOR/EyoiaPWXf97IZYC/JepKCund hYbDdjbL4tT0jl6mQAt4rW8QeteC4MLnSvG98RtPfLchkFNatifvNJZvT0vDHRDw k7UxUcAyKCCyw6QsWO6PhfgczUMeJxOCtjDRWLGe2jAp/gTwXkrIEULTQ5Hq/eo= Received: by mail.winserver.com (Wildcat! SMTP Router v8.0.454.10) for dmarc@ietf.org; Wed, 30 Dec 2020 12:12:22 -0500 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 2788406193.16935.2852; Wed, 30 Dec 2020 12:12:21 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=4130; t=1609347969; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=Xxlw9E0 RVIUDtaE798+SXzg9f1A7P2Tx4QlnrCMN94A=; b=k0yAhU4HNDX8L12Yogvg3RI jyz7qDqWSddjd+TAsA3pP4QGmIVnLQVPh7tBPkCaZb4sbdZ+qvkrIddAPGX4vaOq DbQbPx3PK6N6FtvHHpF7T0gfjZXkxo8+YJqW+i8Om3Dd0ZcL06Xt4/rYqXGGArOu fmeptcznZqPaonYVM5Uw= Received: by beta.winserver.com (Wildcat! SMTP Router v8.0.454.10) for dmarc@ietf.org; Wed, 30 Dec 2020 12:06:09 -0500 Received: from [192.168.1.68] ([75.26.216.248]) by beta.winserver.com (Wildcat! SMTP v8.0.454.10) with ESMTP id 2655274017.1.19316; Wed, 30 Dec 2020 12:06:08 -0500 Message-ID: <5FECB4F6.2020702@isdg.net> Date: Wed, 30 Dec 2020 12:12:22 -0500 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: <9f6782b1-e85b-1a9c-9151-98feff7e18ea@mtcc.com> <140485eb-020f-4406-3f2f-e2c475ea51e5@mtcc.com> <5588dbbe-b876-ed80-c80f-792380e3718f@mtcc.com> <54dd9978-bcd1-6757-ad27-dcef6db6e5f7@mtcc.com> <937f1019-a028-308d-2a0f-1e720fd49dcd@mtcc.com> <72e20c17-e991-e82a-9120-a27097e3ac58@mtcc.com> <7863d250-f56a-1fe1-44ee-fbc7486d48b4@mtcc.com> In-Reply-To: <7863d250-f56a-1fe1-44ee-fbc7486d48b4@mtcc.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] auth-res vs. dmarc X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Dec 2020 17:12:35 -0000 On 12/30/2020 10:41 AM, Michael Thomas wrote: > DMARC != Auth-res. Auth-res provides all kinds of useful information > than just pass/fail. For DMARC Auth-res should provide what the policy > was at a bare minimum. But none of this seems to have any normative > language anywhere which is a problem unto itself. DMARC in auth-res > seems to be an orphan. A-R was a moving target for a long period and I am not sure it is completed for the task at hand. It was why my own wcSMTP used name space field values and made use of for potential visual reports, wcAVS filters at the backend and potentially the MUA frontend. That has always been a consideration since day one. But it was also a consideration the MUA filter could only safely apply it to messages verified by the host, i.e. the A-R record MUST was created by the host by domain name which the MUA client trust. This brings up the important fact, the most mail host have a responsibility to filter "bad" mail before the user gets it and not pass it on to potential phishable users. However, in this real market, like even in this WG, we have both camps; those who believe strongly in rejection at SMTP (system wide) and those who believe of accepting all and passing the buck to the user (user-level filters). IMO, you can't fight it. You accept both and program for both because both exist. For example for Mike's message, its a simple A-R: Authentication-Results: dkim.winserver.com; dkim=pass header.d=ietf.org header.s=ietf1 header.i=ietf.org; dkim=pass header.d=ietf.org header.s=ietf1 header.i=ietf.org; dkim=fail (DKIM_BODY_HASH_MISMATCH) header.d=mtcc.com header.s=fluffulence header.i=mtcc.com; There are no DKIM-POLICY protocol records like ADSP or DMARC. No A-R line for DMARC means the domain have NO record. It is not participating in DMARC, purposely or not. Having no A-R line avoids making erroneous interpretations by consumer like Mike has pointed out. Any A-R evaluation looking for the specific DMARC verification bits as part of its algorithm, but sees none, MUST use the default input and output values for a domain that lacks a DMARC record. For DMARC, when no record exist, the default values are (please confirm, I am going off my https://secure.winserver.com/public/wcDMARC wizard form values). p=none sp=none adkim=relaxed aspf=relaxed pct=100% rua=0 ruf=0 rf=afrf ri=86400 The dmarc= value SHOULD not be dmarc=fail nor dmarc=pass because no DMARC record exist. So if an A-R is written for a non-DMARC domain, it should be perhaps write: dmarc=unknown author.d=gmail.com signer.d=gmail.com (originating signer); or dmarc=none author.d=gmail.com signer.d=gmail.com (originating signer); Although the dmarc=none could erroneously suggest a DMARC record exist with a p=none policy, when a real policy exist, then a policy= tag used in our A-R, like: dmarc=dkim-fail policy=none author.d=gmail.com signer.d=gmail.com (originating signer); which reads: The author.d=gmail.com has a DMARC none policy. It has an aligned author and signer domain, but DMARC failed due to a dkim-fail signature which the A-R dkim line shows: dkim=fail (DKIM_BODY_HASH_MISMATCH) header.d=gmail.com header.s=20161025 header.i=gmail.com; I am not suggesting this or no DMARC A-R line should be written when the domain lacks a DMARC record. If a A-R dmarc line is recorded, it should be readable by humans. It should not erroneously misdirect an A-R evaluator routine when a DMARC does not exist. Using the comment field SHOULD be reserved for non-standard HUMAN readable data. But some of used it to fill in the gaps we wanted A-R for verification results, i.e. for SPF, the ip name field. Overall, I agree, resolving the A-R name space technical issue SHOULD be resolve in the WG for DMARC-bis. I think it is well worth the effort to define what we need and then use this for the update up the A-R specs to create a more common and useful name space to all. -- Hector Santos, https://secure.santronics.com https://twitter.com/hectorsantos From nobody Wed Dec 30 09:16: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 870EF3A0A22 for ; Wed, 30 Dec 2020 09:16:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, 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=mtcc.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 WEKQWfNuJ2w9 for ; Wed, 30 Dec 2020 09:16:11 -0800 (PST) Received: from mail-pj1-x1034.google.com (mail-pj1-x1034.google.com [IPv6:2607:f8b0:4864:20::1034]) (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 E18E13A0A1E for ; Wed, 30 Dec 2020 09:16:11 -0800 (PST) Received: by mail-pj1-x1034.google.com with SMTP id f14so3671490pju.4 for ; Wed, 30 Dec 2020 09:16:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mtcc.com; s=fluffulence; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=HkP/tYvZenAKCwv4VepNUH12wKNk3BhNYKyAAHVL8SM=; b=MuZGSZZruiBWF3g8AwTMKrZ5VPOxwGYiDHLmt8Z6X8UpSESJpU2L6sii+whqHdVQdF U5WPVi1aLhVfp3YUvctsb2Pifyb+HC5Zw2PeV+aEET/D3MhIt563cb6oqXvKV3txR+9G ry+Lx3pZ/DkBs6fyoXhNsz7GxvESzd8gISH4tVGf5Z5tFw+8LItJR6TafIRGiS1oVkei 7ZER49ACECF55KWG3TyNMHwn3q7o2T/pgue1JycNeFuAP4SZOgvhALNqft0rzepkLK7f qsTmvIdRpGGhwyDvpW54lUbH7TJhwY+DrcITt8oAlFJtVUmbUTWKb4vz8j4FNYx72C6P PXiw== 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=HkP/tYvZenAKCwv4VepNUH12wKNk3BhNYKyAAHVL8SM=; b=tzztsFzbA07Nu2iKOV81pA5H72U9YeGYxJdlPctY45Z+g9wNEL2/Pxf6mZyonoLdWv VXlTr3usAKWSjtvpQOddUZS4A5Qwh/8vKSaYuryGT2/n7GLVlRF8+GTIMt2trcD45koi pDVxG2A1KW8bHB7z8cn7K8OtmaJPqdwEGZlgVuKoBj7jQ72IYbY4HhR9ZT/ofHl3mQrw FzpNAhYvbuDyE/9XNPDhF2EQgQLfzBqwDbJcUI/xcJgCaMI9SBQrJnJNt6wU3NxZBN95 OXnDaCO/xwtO0ko4KbvoVZ7QFdOFUPshlM6HWOvlt5nmhwWVTo/ZQdJSzL5kgaj1NBGY dosQ== X-Gm-Message-State: AOAM533xj6x8ZyV8L0lLHm4PaeQEZOELDp+DURmKWa86OYdO91TKlzpY j8yr9ul7sTNxf9BmNn2vlHejzF9pYz6LtQ== X-Google-Smtp-Source: ABdhPJyp6rLGVFq3ElwoelS2TXU7pOFvJiMn028rdKTASlJWZmVi3vtpLNQN4sbVM9Dbu0JpMYYaGA== X-Received: by 2002:a17:902:a512:b029:db:cf4c:336b with SMTP id s18-20020a170902a512b02900dbcf4c336bmr53967142plq.17.1609348570872; Wed, 30 Dec 2020 09:16:10 -0800 (PST) Received: from mike-mac.lan (107-182-45-95.volcanocom.com. [107.182.45.95]) by smtp.gmail.com with ESMTPSA id u25sm41531183pfn.101.2020.12.30.09.16.09 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 30 Dec 2020 09:16:10 -0800 (PST) To: Seth Blank Cc: Dotzero , IETF DMARC WG References: <9f6782b1-e85b-1a9c-9151-98feff7e18ea@mtcc.com> <5588dbbe-b876-ed80-c80f-792380e3718f@mtcc.com> <54dd9978-bcd1-6757-ad27-dcef6db6e5f7@mtcc.com> <937f1019-a028-308d-2a0f-1e720fd49dcd@mtcc.com> <72e20c17-e991-e82a-9120-a27097e3ac58@mtcc.com> <7863d250-f56a-1fe1-44ee-fbc7486d48b4@mtcc.com> From: Michael Thomas Message-ID: <0b0c0c7c-f374-6718-5071-b5e9b0d67db3@mtcc.com> Date: Wed, 30 Dec 2020 09:16:08 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.6.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] auth-res vs. dmarc X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Dec 2020 17:16:15 -0000 On 12/30/20 8:42 AM, Seth Blank wrote: > At this point, this thread is deeply unproductive and preventing work > on open tickets. > > Mike, I hear that you believe better normative accounting for DMARC > results in auth-res is needed. If this is correct, please open a > ticket, and the working group will address it later as we've committed > to discussing all open tickets. > Later? How much later? Looking at the open tickets it looks you have about 5 more years of "later". And I would say the chairs teeing up tickets would be a far more efficient means of driving the process than shutting down discussions that will become tickets. That other thread on privacy should have been closed out weeks ago. I believe there are several separate issues: 1) There is a scaling issue for DMARC if it is required to be used beyond the boundary of an administrative domain, and especially if MUA's start running them; there is nothing that says that they can't or shouldn't. 2) Auth-res process-wise is an orphan with no means of discussing it in any working group even though it's standards track and has issues requiring coordination with this working group 3) The fundamental question that Ned brought up which is whether Auth-res is a protocol at all. If it's really just a debugging tool to be use by humans, it should definitely just be informational, and probably historic. Either Auth-res is useful and supported or not and should be killed 4) Should DMARC require a normative Authentication-Results Requirements section? This process-wise would solve the problem of auth-res in (2) and shift the specification of that normative text back to the document that is affected by it, letting Auth-res just be a transport vehicle so that it doesn't require yet another working group-less update. That is what we should have done from the start, but auth-res is an accident of history. Mike From nobody Wed Dec 30 09:21: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 D29103A0A2D for ; Wed, 30 Dec 2020 09:20:59 -0800 (PST) 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 OnDxK7dqNHue for ; Wed, 30 Dec 2020 09:20:58 -0800 (PST) Received: from mail-vk1-xa36.google.com (mail-vk1-xa36.google.com [IPv6:2607:f8b0:4864:20::a36]) (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 E11793A0A26 for ; Wed, 30 Dec 2020 09:20:57 -0800 (PST) Received: by mail-vk1-xa36.google.com with SMTP id a6so3760288vkb.8 for ; Wed, 30 Dec 2020 09:20:57 -0800 (PST) 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=HJjJhGwasDAAiVtBBj+EHVlsZN+D/ANY9UmmgjL6zVc=; b=O4JNHkiieldV9KtFCCyUVxYwvxdnXOQhoIoRaUkniJaRkirFl5BW/o3TB5xpE4przH v8Zkvcva/fpn9yDBw2ybkJmXxMo+rDV/cYJtahp9b9jU5hTxHJILjl9bOUa+dcJ9D3WQ xOA7be4xJ9uZh6vAJSFNT0Z3Bv4jzMrdzIECNzV7ZzoNGzeFoMbvNrFk3BdRdxNlpEBG ylG0MdoUEdDmU4kcPuzXHh8dKje4Q1KHer3HDmJ1lzCJJV3tWhvxs+ZQ7icTMAD4c3jc 6LWN1A3aL7K0py77CVuKybRPLZs7nAciS50TxzETZFM8iJZ7cJ1SMotLNLk+o5U60a4S SVDg== 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=HJjJhGwasDAAiVtBBj+EHVlsZN+D/ANY9UmmgjL6zVc=; b=fhBwXGuX4v565OSTt947O1LJfDDysumK+b6ZBlFh9UzVL5auQzWunqkgM+Glg9rH5s YptFzb+ln04adLx7634NkCLuxE0SUpmpfpK5rO+w2wDSQQoD0ZVbz987jJdHBJka+WyP 9Mn6UpcMTSp+Yx9gBM1L36FHCYngpQDJCqdLcNMffbh3hXGGHAHkwDfrrHokd7nnMMnu zDnrWnF9f2TPR1IQAvfefygnM2r9tcLG3aJKPWx9w15VR2IgMFgnwir4GxXqBBVfwFgj Hbgu2iXHAL3eZo6MS03o4wcwV5izvvrZ2C14IjhL61weibDjJO8KM97Lect69ZyDyurw 49/w== X-Gm-Message-State: AOAM532iHac/Z5jY7cBy+NjdJjO5fJfJmWoJOnOCTrHU0wu7DmTNmnuS +2r9yapkbaby7pcfs1Q5r0PRPwixgwG7J68Ik4my0Q== X-Google-Smtp-Source: ABdhPJwvv2AKsZf35H9zP8ycQ+UpDNLAWi3pJeyUW5hLjXempmhoPTq2nzyH0tgNcSmtOOVkkTKNZXg2PtX5Q3tKC2c= X-Received: by 2002:a1f:22d7:: with SMTP id i206mr25239892vki.4.1609348856838; Wed, 30 Dec 2020 09:20:56 -0800 (PST) MIME-Version: 1.0 References: <9f6782b1-e85b-1a9c-9151-98feff7e18ea@mtcc.com> <5588dbbe-b876-ed80-c80f-792380e3718f@mtcc.com> <54dd9978-bcd1-6757-ad27-dcef6db6e5f7@mtcc.com> <937f1019-a028-308d-2a0f-1e720fd49dcd@mtcc.com> <72e20c17-e991-e82a-9120-a27097e3ac58@mtcc.com> <7863d250-f56a-1fe1-44ee-fbc7486d48b4@mtcc.com> <0b0c0c7c-f374-6718-5071-b5e9b0d67db3@mtcc.com> In-Reply-To: <0b0c0c7c-f374-6718-5071-b5e9b0d67db3@mtcc.com> From: Seth Blank Date: Wed, 30 Dec 2020 09:20:45 -0800 Message-ID: To: Michael Thomas Cc: Dotzero , IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000ee91b205b7b1ba14" Archived-At: Subject: Re: [dmarc-ietf] auth-res vs. dmarc X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Dec 2020 17:21:00 -0000 --000000000000ee91b205b7b1ba14 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Please follow the process stated by the chairs, open the tickets, and we=E2= =80=99ll tear through the items. It=E2=80=99s disruptive threads that take us off ta= sk and make it feel like =E2=80=9Cfive years=E2=80=9D worth of tickets. Most in th= e tracker are simple and close to NOOPs if we stay focused. Seth, as Chair On Wed, Dec 30, 2020 at 09:16 Michael Thomas wrote: > > On 12/30/20 8:42 AM, Seth Blank wrote: > > At this point, this thread is deeply unproductive and preventing work > > on open tickets. > > > > Mike, I hear that you believe better normative accounting for DMARC > > results in auth-res is needed. If this is correct, please open a > > ticket, and the working group will address it later as we've committed > > to discussing all open tickets. > > > Later? How much later? Looking at the open tickets it looks you have > about 5 more years of "later". And I would say the chairs teeing up > tickets would be a far more efficient means of driving the process than > shutting down discussions that will become tickets. That other thread on > privacy should have been closed out weeks ago. > > I believe there are several separate issues: > > 1) There is a scaling issue for DMARC if it is required to be used > beyond the boundary of an administrative domain, and especially if MUA's > start running them; there is nothing that says that they can't or > shouldn't. > > 2) Auth-res process-wise is an orphan with no means of discussing it in > any working group even though it's standards track and has issues > requiring coordination with this working group > > 3) The fundamental question that Ned brought up which is whether > Auth-res is a protocol at all. If it's really just a debugging tool to > be use by humans, it should definitely just be informational, and > probably historic. Either Auth-res is useful and supported or not and > should be killed > > 4) Should DMARC require a normative Authentication-Results Requirements > section? This process-wise would solve the problem of auth-res in (2) > and shift the specification of that normative text back to the document > that is affected by it, letting Auth-res just be a transport vehicle so > that it doesn't require yet another working group-less update. That is > what we should have done from the start, but auth-res is an accident of > history. > > Mike > > -- *Seth Blank* | VP, Standards and New Technologies *e:* seth@valimail.com *p:* 415.273.8818 This email and all data transmitted with it contains confidential and/or proprietary information intended solely for the use of individual(s) authorized to receive it. If you are not an intended and authorized recipient you are hereby notified of any use, disclosure, copying or distribution of the information included in this transmission is prohibited and may be unlawful. Please immediately notify the sender by replying to this email and then delete it from your system. --000000000000ee91b205b7b1ba14 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Please follow the process stated by the chairs, open the = tickets, and we=E2=80=99ll tear through the items. It=E2=80=99s disruptive = threads that take us off task and make it feel like =E2=80=9Cfive years=E2= =80=9D worth of tickets. Most in the tracker are simple and close to NOOPs = if we stay focused.

Seth= , as Chair

On Wed, Dec 30, 2020 at 09:16 Michael Thomas <mike@mtcc.com> wrote:

On 12/30/20 8:42 AM, Seth Blank wrote:
> At this point, this thread is deeply unproductive and preventing work =
> on open tickets.
>
> Mike, I hear that you believe better normative accounting for DMARC > results in auth-res is needed. If this is correct, please open a
> ticket, and the working group will address it later as we've commi= tted
> to discussing all open tickets.
>
Later? How much later? Looking at the open tickets it looks you have
about 5 more years of "later". And I would say the chairs teeing = up
tickets would be a far more efficient means of driving the process than shutting down discussions that will become tickets. That other thread on privacy should have been closed out weeks ago.

I believe there are several separate issues:

1) There is a scaling issue for DMARC if it is required to be used
beyond the boundary of an administrative domain, and especially if MUA'= s
start running them; there is nothing that says that they can't or shoul= dn't.

2) Auth-res process-wise is an orphan with no means of discussing it in any working group even though it's standards track and has issues
requiring coordination with this working group

3) The fundamental question that Ned brought up which is whether
Auth-res is a protocol at all. If it's really just a debugging tool to =
be use by humans, it should definitely just be informational, and
probably historic. Either Auth-res is useful and supported or not and
should be killed

4) Should DMARC require a normative Authentication-Results Requirements section? This process-wise would solve the problem of auth-res in (2)
and shift the specification of that normative text back to the document that is affected by it, letting Auth-res just be a transport vehicle so that it doesn't require yet another working group-less update. That is =
what we should have done from the start, but auth-res is an accident of history.

Mike

--

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


<= /p>

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

--000000000000ee91b205b7b1ba14-- From nobody Wed Dec 30 09:34: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 B2C453A0AB8 for ; Wed, 30 Dec 2020 09:34:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.399 X-Spam-Level: X-Spam-Status: No, score=-4.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_MED=-2.3, 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 1-dAYNkFSZI2 for ; Wed, 30 Dec 2020 09:34:39 -0800 (PST) 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 E3EF63A0AB7 for ; Wed, 30 Dec 2020 09:34:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1609349677; bh=+4t6A9V50BVEizjFjyAB+QeTectBoScDAClc0AGsK28=; l=3571; h=To:References:From:Date:In-Reply-To; b=CwL13pWq2p8WgyZ4mOhODzre7h9XAA+BOu1NRsfOC47cogoBViNAc+akhTCt1K/FG pdzb40XJMg7thTgFoDsKacaLmqvuyNFaBI6XlPjOsAor2iBv1OP3f91u66WcPSkDgC ho60TXFaORhU/pGC8fBWAFAFEgJ+aubTM63jIyKwvxDuui6D8JfBXs2gn3SDa Authentication-Results: tana.it; auth=pass (details omitted) Original-From: Alessandro Vesely 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 00000000005DC0BB.000000005FECBA2D.000058CC; Wed, 30 Dec 2020 18:34:37 +0100 To: Dotzero , Michael Thomas , IETF DMARC WG References: <9f6782b1-e85b-1a9c-9151-98feff7e18ea@mtcc.com> <140485eb-020f-4406-3f2f-e2c475ea51e5@mtcc.com> <5588dbbe-b876-ed80-c80f-792380e3718f@mtcc.com> <54dd9978-bcd1-6757-ad27-dcef6db6e5f7@mtcc.com> <937f1019-a028-308d-2a0f-1e720fd49dcd@mtcc.com> <72e20c17-e991-e82a-9120-a27097e3ac58@mtcc.com> <7863d250-f56a-1fe1-44ee-fbc7486d48b4@mtcc.com> From: Alessandro Vesely Message-ID: <6b92109b-5dea-5d28-c52c-bbe33d168c7b@tana.it> Date: Wed, 30 Dec 2020 18:34:36 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.6.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] auth-res vs. dmarc X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Dec 2020 17:34:41 -0000 On Wed 30/Dec/2020 17:22:07 +0100 Dotzero wrote: > On Wed, Dec 30, 2020 at 10:41 AM Michael Thomas wrote: >> On 12/30/20 7:35 AM, Todd Herr wrote: >> On Wed, Dec 30, 2020 at 9:01 AM Michael Thomas wrote: >>> On 12/30/20 5:48 AM, Todd Herr wrote: >>> >>>>> I propose to add two new result name codes, named after the policy >>>>> requests: >>>>> >>>>> dmarc=quarantine, and >>>>> >>>>> dmarc=reject (of course, you only see this if the filter didn't >>>>> honor the request). >>>> >>>> I do not support this, because quarantine, reject, and none are not >>>> Authentication Results, but are instead both policy requests and >>>> disposition decisions. >>> >>> Then we should remove DMARC from auth-res altogether because it is not an >>> authentication mechanism. Either we fully support DMARC in auth-res or >>> remove it. This half-assed state of unlessness serves nobody. >>> >> I disagree. DMARC has rules that determine whether or not a message is >> deemed to be authenticated - did it pass SPF or DKIM and did it do so >> with a domain that aligns with the RFC5322.From domain. The currently >> valid states for those rules are pass, fail, temperror, and permerror. They are not enough to convey the information needed. That's why I propose an addition. >> Policy and disposition (none, quarantine, reject) apply to decisions made >> based on the authentication results; they are not states for the >> authentication checks themselves. They become states for the authentication check in the moment that we publish that dmarc=quarantine means the message failed DMARC check and the DMARC record asked that the message be quarantined in that case. Todd clearly said that a mailbox provider currently has to resort to temporary header fields in order to communicate results of authentication checks to a downstream, non-standard agent. Perhaps like so: X-Authentication-Results: dmarc=quarantine? Mail systems are not the prerogative of large mailbox providers who roll out their own code. Standards exist to allow compliant code to interoperate. >> DMARC != Auth-res. Auth-res provides all kinds of useful information than >> just pass/fail. For DMARC Auth-res should provide what the policy was at a >> bare minimum. But none of this seems to have any normative language >> anywhere which is a problem unto itself. DMARC in auth-res seems to be an >> orphan. > > You just stated the case as to why this discussion should be ruled out of > scope. " DMARC != Auth-res." and " DMARC in auth-res seems to be an orphan" > > This is the IETF DMARC working group, not the AUTH-RES working group. Indeed. Auth-Res values and meaning are defined precisely in the document we are writing. RFC 8601 is extensible, and it only covers methods that were already in use in 2009, when RFC 5451 came out. > You gave the example of someone writing a crappy Thunderbird extension as a > reason for the working group to change its focus. The code that Philippe Lieser wrote is strictly conforming to standards. It is crappy only because the DMARC standard is, at least as far as specifying authentication methods is concerned. > Perhaps getting the extension author to fix their extension might be a more > fruitful effort. By my bitty knowledge of Philippe's reasoning, I'd bet he'd ask what RFC says where to get a different status than what his add-on displays. Of course he's not going to tentatively parse every known A-R comment. Best Ale -- From nobody Wed Dec 30 09:41: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 B92143A0ACC for ; Wed, 30 Dec 2020 09:41:13 -0800 (PST) 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 4V3oQU9Ka-Y6 for ; Wed, 30 Dec 2020 09:41:12 -0800 (PST) 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 0A7E63A0AC3 for ; Wed, 30 Dec 2020 09:41:11 -0800 (PST) Received: by mail-qk1-x72c.google.com with SMTP id w79so14489337qkb.5 for ; Wed, 30 Dec 2020 09:41:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=BEiyFahTEKqD7smazZgf9QPHITK3T5Taf9V10DT/GqY=; b=Xl/+C9RLnhGBLM1XLkpHLuG1xdqOolBitZ6k1dpQXvwgujevxA9elVZble/b+jqEe0 7W6YPXMe+soZNbyj1ha8CK5AgwFga9Ya31ifUvSbKnSQwG0Yl+4x6tzVOeyfIXlXIlA/ KRweNrhnw9juwIPyv69SyHb3e0g5Vil5xvlaA68rs0drEB7wWcS7Ao8LSeULRayH8emL I1ehQtg/K30Sz6ZAdFYbcqvjIteK36vJd6yKVjjDojgjRmeqXynAkiKV6SeHZWeUwgbZ ta5d8zd0EY4/o7S5LetoqRok5Pvqs1quDzR3bv+/owZP3P0uJqknyF26Q+A8yjNGfPcS m0Yg== 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=BEiyFahTEKqD7smazZgf9QPHITK3T5Taf9V10DT/GqY=; b=gnxHSITmIWGl8bTP2ktLcYCTLrHWoJ61TF+DgwSldbYzaE0tfVKirxS9vLFTnBX+an YwfHujLX0/l4kwXlaIDQCKWtYpO+bJir/6BRT+hf+HdBaH3ew/iAxg68XkAOKlyQYWp/ WR0GkCA3UmvuLM6NFC+KHh9364xw/2FKEAcGhLmxaIfG7/WxYyxg0MRSHBeSpbmw9BNL LnejOCxWMwUBnVZgUbC4wjsr/tBs6PNLUQzNvOYhQZaEE6ljOkpRDDfcwNGmxrrWf0Ma W24yeDDL3P8HGohnJDVXN0a4jwm6WDWDCcHYajIBJ8JtVqWdDPTAx7eucNsiBJie0SBj b7Jw== X-Gm-Message-State: AOAM533vv3f32AK18Lm6MMEqAQx/bF/4iWTpjswpBVSvJb11TmgaeIFW AwDaW1FcigIa5VAaC4ktTa1R7hGoCSX2atJFZBQbSNM/BUs= X-Google-Smtp-Source: ABdhPJyMmDMXK/6RB9IhJ6dRcfC2eb1nMPseG+PuOz1OZ2hFoV3KRPiCg0ROw4c6/+VQBCW2spv2QS5NmVYtaEhYLKg= X-Received: by 2002:a37:a058:: with SMTP id j85mr55991992qke.387.1609350070572; Wed, 30 Dec 2020 09:41:10 -0800 (PST) MIME-Version: 1.0 References: <9f6782b1-e85b-1a9c-9151-98feff7e18ea@mtcc.com> <140485eb-020f-4406-3f2f-e2c475ea51e5@mtcc.com> <5588dbbe-b876-ed80-c80f-792380e3718f@mtcc.com> <54dd9978-bcd1-6757-ad27-dcef6db6e5f7@mtcc.com> <937f1019-a028-308d-2a0f-1e720fd49dcd@mtcc.com> <72e20c17-e991-e82a-9120-a27097e3ac58@mtcc.com> <7863d250-f56a-1fe1-44ee-fbc7486d48b4@mtcc.com> <6b92109b-5dea-5d28-c52c-bbe33d168c7b@tana.it> In-Reply-To: <6b92109b-5dea-5d28-c52c-bbe33d168c7b@tana.it> From: Todd Herr Date: Wed, 30 Dec 2020 12:40:54 -0500 Message-ID: To: IETF DMARC WG Content-Type: multipart/alternative; boundary="00000000000046b28e05b7b20340" Archived-At: Subject: Re: [dmarc-ietf] auth-res vs. dmarc X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Dec 2020 17:41:14 -0000 --00000000000046b28e05b7b20340 Content-Type: text/plain; charset="UTF-8" On Wed, Dec 30, 2020 at 12:34 PM Alessandro Vesely wrote: > > Todd clearly said that a mailbox provider currently has to resort to > temporary > header fields in order to communicate results of authentication checks to > a > downstream, non-standard agent. Perhaps like so: > > I know we're supposed to let this thread die, but I wanted to clarify something here. It was not my intent to say "a mailbox provider has to resort to temporary header fields in order to communicate results..." What I was trying to say is "Absent our working for a given mailbox provider, we don't know which header(s) are used by the mailbox provider to convey message disposition and display information to their MDAs and UIs." I apologize for the confusion. -- *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. --00000000000046b28e05b7b20340 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Dec 30, 2020 at 12:34 PM Ales= sandro Vesely <vesely@tana.it> = wrote:

Todd clearly said that a mailbox provider currently has to resort to tempor= ary
header fields in order to communicate results of authentication checks to a=
downstream, non-standard agent.=C2=A0 Perhaps like so:


I know we're supposed to let this = thread die, but I wanted to clarify something here.

It was not my intent to say "a mailbox provider has to resort to tem= porary header fields in order to communicate results..."
What I was trying to say is "Absent our working for a give= n mailbox provider, we don't know which header(s) are used by the mailb= ox provider to convey message disposition and display information to their = MDAs and UIs."

I apologize for the confusion.= =C2=A0

--

To= dd Herr | Sr. Technical Program Manager
p: 703.220.4153


This email and all data transmitte= d with it contains confidential and/or proprietary information intended sol= ely for the use of individual(s) authorized to receive it. If you are not a= n intended and authorized recipient you are hereby notified of any use, dis= closure, copying or distribution of the information included in this transm= ission is prohibited and may be unlawful. Please immediately notify the sen= der by replying to this email and then delete it from your system.

--00000000000046b28e05b7b20340-- From nobody Wed Dec 30 10:02: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 341AF3A0B18 for ; Wed, 30 Dec 2020 10:02:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, 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=mtcc.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 bPZwuRZZfOUz for ; Wed, 30 Dec 2020 10:02:53 -0800 (PST) Received: from mail-pg1-x52c.google.com (mail-pg1-x52c.google.com [IPv6:2607:f8b0:4864:20::52c]) (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 3A9BB3A0B16 for ; Wed, 30 Dec 2020 10:02:53 -0800 (PST) Received: by mail-pg1-x52c.google.com with SMTP id i7so11743275pgc.8 for ; Wed, 30 Dec 2020 10:02:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mtcc.com; s=fluffulence; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=eVfwUTphqsOBCRiQ6E+JAtxwg7ZGB439KeQ3lpCIyZ4=; b=fdnJW8I+xjfiDKUXdYJRRxoV9lwDKOz5hvmN85VIclaaEzGqyFZER5Amh4efxcThpu FKOOa27dUxH4OFVhQ4JVNIyg05vVw3Hl/v2eSBkCTbGUOw+8vf/KVDzAAgo482HUUskk iAmNJS2iFve3KzWgG6J3vcGIvWptCwK0GPYPYXl0ODiH1CxzrZJYmqWPS5Z8vN7eX+yA iOLy28PethyvDgoFlLQFfbxmNBU596sokA8qiyseIYeAQi04Xd+4n1o/+1/VIqVnGX0+ Wuyg68FQegoLPlH18vl1pg75FcZbmXCGGjGYzfOOdcQrp/1wxMrgEeTKQqQPXfvYPYAt xxZQ== 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=eVfwUTphqsOBCRiQ6E+JAtxwg7ZGB439KeQ3lpCIyZ4=; b=sEWe+3i+sQQJycIwDskzvuOK0RPvxIzn+hdrjev0834yvXtdxNxW35rYdNmp93C/Uj o4gcA8CSnNW+/PPlf41rxNrVN31iCscDJpwtcyFsHOAJGOruCLKGW/XGAVzkYGQUfKEz On6/aioy8m2nMhnrQjvIrDE7/TKMaBfx2/4EAfvc2X0d34rFbu+GBRjZ/8Ohim+JR/v0 RYhBINo9G1ZwAyMefsDMJOQJP6DFoOckZo7oCL5ZNqYhz0WQKlTs3/w38zPik3MqiGFi VO6Z2N+mo3vRuDUvc/xlhHemrRoIceRVlm/JBzQEpQdM0pldXTahLYfFPWQX+N0mTkjw bIOA== X-Gm-Message-State: AOAM533hPNX2a8dECnwpS2Kh/lFbO/Q2eHhd5qnSPB0cKyDfDBMcBtkO YeaXzMO8GijPzV/2KaM3JHwwX3zd+2if2Q== X-Google-Smtp-Source: ABdhPJz/9pe2wTDCXZHzJwUqSpUbrNtE9P1qp9MhloeCnlBG3ilVBffyE/emSmeTWQsXNo0sRAkQpw== X-Received: by 2002:a63:ea4b:: with SMTP id l11mr52626494pgk.61.1609351372070; Wed, 30 Dec 2020 10:02:52 -0800 (PST) Received: from mike-mac.lan (107-182-45-95.volcanocom.com. [107.182.45.95]) by smtp.gmail.com with ESMTPSA id b12sm13484654pgr.9.2020.12.30.10.02.50 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 30 Dec 2020 10:02:51 -0800 (PST) To: Seth Blank Cc: Dotzero , IETF DMARC WG References: <9f6782b1-e85b-1a9c-9151-98feff7e18ea@mtcc.com> <54dd9978-bcd1-6757-ad27-dcef6db6e5f7@mtcc.com> <937f1019-a028-308d-2a0f-1e720fd49dcd@mtcc.com> <72e20c17-e991-e82a-9120-a27097e3ac58@mtcc.com> <7863d250-f56a-1fe1-44ee-fbc7486d48b4@mtcc.com> <0b0c0c7c-f374-6718-5071-b5e9b0d67db3@mtcc.com> From: Michael Thomas Message-ID: <55cbdb92-0e7b-d334-1e26-463452ea476c@mtcc.com> Date: Wed, 30 Dec 2020 10:02:49 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.6.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] auth-res vs. dmarc X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Dec 2020 18:02:54 -0000 On 12/30/20 9:20 AM, Seth Blank wrote: > Please follow the process stated by the chairs, open the tickets, and > we’ll tear through the items. It’s disruptive threads that take us off > task and make it feel like “five years” worth of tickets. Most in the > tracker are simple and close to NOOPs if we stay focused. > Filed. And I still have no  idea what tickets we're actually supposed to be talking about. And since when did IETF process require tickets to be opened to discuss issues? Mike From nobody Wed Dec 30 10:13: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 3355B3A0A3E for ; Wed, 30 Dec 2020 10:13:25 -0800 (PST) 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, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 XoKFtvDN8y6n for ; Wed, 30 Dec 2020 10:13:24 -0800 (PST) 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 C5E5F3A0062 for ; Wed, 30 Dec 2020 10:13:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1609352001; bh=SOT/EjUlyJJwcUsDskySlVEKPNcXZfRUDgMTVuys/E8=; l=329; h=To:References:From:Date:In-Reply-To; b=BWWjuF0yehNUvxcuj1tcV5xI857BbWYB/D9FheqgnJBXk0ySfBWTnyPETOVJuYn4q shyN8ip42p0QSlOH+fCDEvggz/3845H2fqI/rl5VM5Ml7evhOafsCRYgpMrq/xkPMo DbVYmc/ZiTh0qROXloh5AEQ6jSbJ9yktfIBLR59yxlpClhA5JwmU0KuA4tfAO Authentication-Results: tana.it; auth=pass (details omitted) Original-From: Alessandro Vesely 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.000000005FECC341.00005D92; Wed, 30 Dec 2020 19:13:21 +0100 To: IETF DMARC WG References: <9f6782b1-e85b-1a9c-9151-98feff7e18ea@mtcc.com> <5588dbbe-b876-ed80-c80f-792380e3718f@mtcc.com> <54dd9978-bcd1-6757-ad27-dcef6db6e5f7@mtcc.com> <937f1019-a028-308d-2a0f-1e720fd49dcd@mtcc.com> <72e20c17-e991-e82a-9120-a27097e3ac58@mtcc.com> <7863d250-f56a-1fe1-44ee-fbc7486d48b4@mtcc.com> <502c2363-385c-b90c-a22a-716594967190@mtcc.com> From: Alessandro Vesely Message-ID: <01fe63df-1960-868a-3351-08a24bb7a9cf@tana.it> Date: Wed, 30 Dec 2020 19:13:21 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.6.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] auth-res vs. dmarc X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Dec 2020 18:13:25 -0000 On Wed 30/Dec/2020 17:38:29 +0100 Dotzero wrote: > And for the second time, that is not a DMARC problem, it is an auth-res problem. Standardizing the result names for dmarc authentication method is an integral part of DMARC specification. Added ticket 91 https://trac.ietf.org/trac/dmarc/ticket/91 Best Ale -- From nobody Wed Dec 30 10:21:39 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B36A93A0B22 for ; Wed, 30 Dec 2020 10:21:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, 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=mtcc.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 CqhomNbH_INP for ; Wed, 30 Dec 2020 10:21:36 -0800 (PST) Received: from mail-pj1-x1034.google.com (mail-pj1-x1034.google.com [IPv6:2607:f8b0:4864:20::1034]) (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 6D4703A0B1F for ; Wed, 30 Dec 2020 10:21:36 -0800 (PST) Received: by mail-pj1-x1034.google.com with SMTP id w1so2271459pjc.0 for ; Wed, 30 Dec 2020 10:21:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mtcc.com; s=fluffulence; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=9udrJhutvdwgFk7uuEpoJfGwuFddjwsAVg2AGgSlkdM=; b=JDGY4nJ6k23SwZzFor3tzNkvhDD1utatZXph0OiEaZHJRlQuVgA3zHTKBJ+q4bAJk8 Lztu5gg/G/mIjE2snH43l4X/lMQHcWA2t5Mwy1iWXTNdXSO1xupy4ADhbJ3N+fenNK6C UilBRrVHdwD5Dj7Hq5CmylQAM4pnp0zsKNmGR1IhipIm71EYNg2KN5MrWLqVDrYUx40q OEQiCQEtjAYKKrDIPlvfG21xy0MYgLhRsD4zx6Xp/G1yL4RmkG7Bg8AEB50CBNMFDqVP AD1WWf6F/rpq/elZRtAiTYSSEveTQifWKzctjksIzjnq+i2akGbhadLFqHw3lk4ehWfx ad7g== 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=9udrJhutvdwgFk7uuEpoJfGwuFddjwsAVg2AGgSlkdM=; b=Sh0dNxnt8rKlJvOyrrQX1ispHfMN7eoBowbtZWkn7+AiIo613rb84zkXcflBzAXMFI +Gp+wT4jOMT5B5BglkS94bVnqevFQj4Mr5ubfKfwV+IPr5V6Vu2W2PW/5Ytm2wG1UyMu frrLFeeMURa9mh5s1scC/4b5t9pvZC64oLguHGy4wwtV135Fx9Q5c520TjZp/rHQFw04 mP9BeZaJ5LojmQ14clBz/bGkeIAiWBNJDBsgLAac3hDF6SJArwKILEhE5Ml2OsjbU8YK PWr23Lv6TvpQkEK1985JQfDPiBZDK3gHv7tZnKc9eorlJxHu69veZ56LeaYR1LB5mX5K 3IcA== X-Gm-Message-State: AOAM530JYCiJ3oPRvWrv/Q51Bg4QvBAci9k8jg3G/AmKqWRfxCVaG3Dg 6DhgISSsmw58TJo0tZLJv2UHfKLH9xVLZA== X-Google-Smtp-Source: ABdhPJwPyNehklnOn2kyoGa0SgcFVnKnCXzeF0Gp2ALNhXOqAo2Y3/5so3jszWpg57C2MTukwaGr3g== X-Received: by 2002:a17:90a:fb97:: with SMTP id cp23mr9927935pjb.215.1609352495303; Wed, 30 Dec 2020 10:21:35 -0800 (PST) Received: from mike-mac.lan (107-182-45-95.volcanocom.com. [107.182.45.95]) by smtp.gmail.com with ESMTPSA id c62sm43417450pfa.116.2020.12.30.10.21.34 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 30 Dec 2020 10:21:34 -0800 (PST) To: dmarc@ietf.org References: <9f6782b1-e85b-1a9c-9151-98feff7e18ea@mtcc.com> <5588dbbe-b876-ed80-c80f-792380e3718f@mtcc.com> <54dd9978-bcd1-6757-ad27-dcef6db6e5f7@mtcc.com> <937f1019-a028-308d-2a0f-1e720fd49dcd@mtcc.com> <72e20c17-e991-e82a-9120-a27097e3ac58@mtcc.com> <7863d250-f56a-1fe1-44ee-fbc7486d48b4@mtcc.com> <502c2363-385c-b90c-a22a-716594967190@mtcc.com> <01fe63df-1960-868a-3351-08a24bb7a9cf@tana.it> From: Michael Thomas Message-ID: <8e1d6a24-17f4-1fa8-d90a-883e3b8e7432@mtcc.com> Date: Wed, 30 Dec 2020 10:21:33 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: <01fe63df-1960-868a-3351-08a24bb7a9cf@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] auth-res vs. dmarc X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Dec 2020 18:21:38 -0000 On 12/30/20 10:13 AM, Alessandro Vesely wrote: > On Wed 30/Dec/2020 17:38:29 +0100 Dotzero wrote: >> And for the second time, that is not a DMARC problem, it is an >> auth-res problem. > > > Standardizing the result names for dmarc authentication method is an > integral part of DMARC specification. > > Added ticket 91 > https://trac.ietf.org/trac/dmarc/ticket/91 > I opened a ticket too which basically says that there should be a normative Authentication-Results Requirements section in the base specifications. That was a process error from the very beginning with auth-res and its weird semi-official status. I don't think it has ever been discussed whether it is even a protocol or not as Ned brought up (opened a ticket on that too). Mike From nobody Wed Dec 30 10:29: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 8E6D93A0D06 for ; Wed, 30 Dec 2020 10:29:43 -0800 (PST) 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 mBw7I-A7FIGm for ; Wed, 30 Dec 2020 10:29:41 -0800 (PST) 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 497E43A0B37 for ; Wed, 30 Dec 2020 10:29:36 -0800 (PST) Received: by mail-vs1-xe2d.google.com with SMTP id e20so8942468vsr.12 for ; Wed, 30 Dec 2020 10:29:36 -0800 (PST) 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=JRiZR5U5hhgfxw/pwp0dKKhj56ogT6d2Zrw1kQ5Uirs=; b=QDyh29XszCMgid5B8ZtsZV4fC33VHFDwvNvVBmYhQXHL3BzYF4EL4TmewpQflOlVKo VdzJU9+dg5mW5rGUtFbF354RWfFBg3dcsxy2ZgcgSn+TUGz4G12kFarhf9T0ixjx6YmJ 2vbzmn6y962qkay9yHnJiiV1X41EqPDMJQ0qj3+Db5ZIODEJrWMGUNl7ZCCBVXXgrYo4 q8Q6fz6B9lOs0xmDe+jxcFz0r2r5wIUQ/gehzl43Zt9ZsHt5BQDZW+MJMqP9oQa0W3XG Z9KTe88U2L0QKpKFKVnio+3Mau/AT2tSJylY/qgGRm4lbcivrl5MS8eDI6OX2vFvy6fw HWCg== 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=JRiZR5U5hhgfxw/pwp0dKKhj56ogT6d2Zrw1kQ5Uirs=; b=lHZYDXbOGj3uKGQMc3mzoq44iKI38TmTrOuFPwAFICdGVfHDnRQtVQNC//GFlzL63v KpowqpIJkbrn31SGr6AJDCWbB3jwvTl7a8PlvL3+nzrKv29bKDB9+BmDnTWEZ3BfWLA/ hFc7REi31t//Y2TxQhIRm4jqczkmXBq4yXvaJ/+emPCrOK7+c8kimJloaT63F9WhSA6X 4zd8BubP9SvW4+aXpkECEYp74lfy7sPyhH3u6/voIVn24yjv6CDyxADbrH6Fan/bkR1h ad++R8A+TIT7HBgvs9LwOanwa8UrJFWxgA4xSQ31JdhcyXg5XKNK+oJ6SaoTPQTjz5EX lnWA== X-Gm-Message-State: AOAM530lC6cOGAzZvOUafLlwfrPrwYtEO8g2boZaSZGsoMu7eRo/N8rC reU6C7duMfjRX0H0KPZmEYYnRTwDLZcDNxOSqHo/pA== X-Google-Smtp-Source: ABdhPJyM+Fi75XevQaxKAlZPMoJXrsGLvTkEBf6yj1NpR/vJOqjYqByviD5niT2RG2PXWl5Nnn91E8aU6ucbAnm54vg= X-Received: by 2002:a05:6102:2427:: with SMTP id l7mr34579578vsi.43.1609352975158; Wed, 30 Dec 2020 10:29:35 -0800 (PST) MIME-Version: 1.0 References: <9f6782b1-e85b-1a9c-9151-98feff7e18ea@mtcc.com> <5588dbbe-b876-ed80-c80f-792380e3718f@mtcc.com> <54dd9978-bcd1-6757-ad27-dcef6db6e5f7@mtcc.com> <937f1019-a028-308d-2a0f-1e720fd49dcd@mtcc.com> <72e20c17-e991-e82a-9120-a27097e3ac58@mtcc.com> <7863d250-f56a-1fe1-44ee-fbc7486d48b4@mtcc.com> <502c2363-385c-b90c-a22a-716594967190@mtcc.com> <01fe63df-1960-868a-3351-08a24bb7a9cf@tana.it> <8e1d6a24-17f4-1fa8-d90a-883e3b8e7432@mtcc.com> In-Reply-To: <8e1d6a24-17f4-1fa8-d90a-883e3b8e7432@mtcc.com> From: Seth Blank Date: Wed, 30 Dec 2020 10:29:23 -0800 Message-ID: To: Michael Thomas Cc: dmarc@ietf.org Content-Type: multipart/alternative; boundary="000000000000674c8905b7b2b0c4" Archived-At: Subject: Re: [dmarc-ietf] auth-res vs. dmarc X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Dec 2020 18:29:44 -0000 --000000000000674c8905b7b2b0c4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thank you filing these tickets. With regards to which tickets are actively open, I=E2=80=99ve asked the doc= ument editors to push on open tickets, stand by. On Wed, Dec 30, 2020 at 10:21 Michael Thomas wrote: > > On 12/30/20 10:13 AM, Alessandro Vesely wrote: > > On Wed 30/Dec/2020 17:38:29 +0100 Dotzero wrote: > >> And for the second time, that is not a DMARC problem, it is an > >> auth-res problem. > > > > > > Standardizing the result names for dmarc authentication method is an > > integral part of DMARC specification. > > > > Added ticket 91 > > https://trac.ietf.org/trac/dmarc/ticket/91 > > > I opened a ticket too which basically says that there should be a > normative Authentication-Results Requirements section in the base > specifications. That was a process error from the very beginning with > auth-res and its weird semi-official status. I don't think it has ever > been discussed whether it is even a protocol or not as Ned brought up > (opened a ticket on that too). > > Mike > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > --=20 *Seth Blank* | VP, Standards and New Technologies *e:* seth@valimail.com *p:* 415.273.8818 This email and all data transmitted with it contains confidential and/or proprietary information intended solely for the use of individual(s) authorized to receive it. If you are not an intended and authorized recipient you are hereby notified of any use, disclosure, copying or distribution of the information included in this transmission is prohibited and may be unlawful. Please immediately notify the sender by replying to this email and then delete it from your system. --000000000000674c8905b7b2b0c4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thank you filing these tickets.
With regards to which tickets are actively open, = I=E2=80=99ve asked the document editors to push on open tickets, stand by.<= /div>

On Wed, Dec 30, 2020 at 10:21 Michael Thomas <mike@mtcc.com> wrote:

On 12/30/20 10:13 AM, Alessandro Vesely wrote:
> On Wed 30/Dec/2020 17:38:29 +0100 Dotzero wrote:
>> And for the second time, that is not a DMARC problem, it is an >> auth-res problem.
>
>
> Standardizing the result names for dmarc authentication method is an <= br> > integral part of DMARC specification.
>
> Added ticket 91
> https://trac.ietf.org/trac/dmarc/ticket/91
>
I opened a ticket too which basically says that there should be a
normative Authentication-Results Requirements section in the base
specifications. That was a process error from the very beginning with
auth-res and its weird semi-official status. I don't think it has ever =
been discussed whether it is even a protocol or not as Ned brought up
(opened a ticket on that too).

Mike

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

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


<= /p>

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

--000000000000674c8905b7b2b0c4-- From nobody Wed Dec 30 10:31: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 B96D23A0B37 for ; Wed, 30 Dec 2020 10:31:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, 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=mtcc.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 Y0pZX2DNoV3F for ; Wed, 30 Dec 2020 10:31:54 -0800 (PST) Received: from mail-pj1-x102c.google.com (mail-pj1-x102c.google.com [IPv6:2607:f8b0:4864:20::102c]) (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 23D303A0B36 for ; Wed, 30 Dec 2020 10:31:53 -0800 (PST) Received: by mail-pj1-x102c.google.com with SMTP id b5so4101133pjl.0 for ; Wed, 30 Dec 2020 10:31:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mtcc.com; s=fluffulence; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=zALvHyJ48Fq6MxlACulCcKrg+zOLm2gpCbh6lkR1lns=; b=I5G1iFMCexnmcSxzeRLjDzsVr4UFKiqVgOeWVuJ77IJJB8FhaL3pcXajs4SIfOhuO3 7rGin8UjPP069fFtPaTpjafP0DtHxQ6Vzp9pAKbucHZcyq++AiCUWAjudzh+E+0eAbBK dxBY1aEGIYkncZslq4K+Qc2DrilI2IEDxzSfBTbn2DD45cb+hoAu/2+xtCBC9P9absns 3p8CZb8qK+XAqZw0K79bRcx1dz4wLT8VXTQBscaywacYEp1cJeM9738LgAEv7ALt1iUQ V+/fVgPRgiQsRZdRupLMepW5jvh8n4gMFax4gXpoQvgx96TceaFEbPk24IIa1iD8x5hX lttA== 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=zALvHyJ48Fq6MxlACulCcKrg+zOLm2gpCbh6lkR1lns=; b=k3jiNgrkhu30rw2zy+DEE3m1s7g5MZ899g60S8VLBur8M79MPRzN3PtYqLF5AwtTfG Oc0fbz0yI//NP0tkuY456xZhZk20+zFzlbm/Lisr1HYcnXC0bUWFteHJBpfRpM46ogdT oLFi+WMI7yS4rbHniGTQvcHbYjzIwet24spBGQRqaTvchuNYrRodVnXar/GY7+O5Oqoy dXwE6zTccB17UMC7WjYRVdjViBAl0PusEIsoBg8o58MdBoHQLdyacYCcql8F0TXOMjzO h/0wTZhRhzZvHGMQjQ7xBWeuLCa5ZdJ3OlnEsmJ06SZmseW/Em8wiusLLpQ2sExcFZ4g JFcg== X-Gm-Message-State: AOAM531kLUM6lamzJbY0MRcTEMNRKk8Odx8TCzzcrWO0WYBPDSxuuL6m suV+PUFKzjpRPgiSzwyVTWF5XR+Si3wefQ== X-Google-Smtp-Source: ABdhPJwdG2jGgapU4WEFzt0kKSJoLxwJ6siZZp/3oq0/aR/1ArFQnNqwefoyX7xr/yrMqSLZNeab9Q== X-Received: by 2002:a17:90b:1918:: with SMTP id mp24mr9556103pjb.45.1609353113135; Wed, 30 Dec 2020 10:31:53 -0800 (PST) Received: from mike-mac.lan (107-182-45-95.volcanocom.com. [107.182.45.95]) by smtp.gmail.com with ESMTPSA id c24sm49964752pgi.71.2020.12.30.10.31.51 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 30 Dec 2020 10:31:52 -0800 (PST) To: Seth Blank Cc: dmarc@ietf.org References: <9f6782b1-e85b-1a9c-9151-98feff7e18ea@mtcc.com> <54dd9978-bcd1-6757-ad27-dcef6db6e5f7@mtcc.com> <937f1019-a028-308d-2a0f-1e720fd49dcd@mtcc.com> <72e20c17-e991-e82a-9120-a27097e3ac58@mtcc.com> <7863d250-f56a-1fe1-44ee-fbc7486d48b4@mtcc.com> <502c2363-385c-b90c-a22a-716594967190@mtcc.com> <01fe63df-1960-868a-3351-08a24bb7a9cf@tana.it> <8e1d6a24-17f4-1fa8-d90a-883e3b8e7432@mtcc.com> From: Michael Thomas Message-ID: <6ef89421-4656-143c-c998-2f167be6c302@mtcc.com> Date: Wed, 30 Dec 2020 10:31:50 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------22881268F1668A0A10D6DFEB" Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] auth-res vs. dmarc X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Dec 2020 18:31:56 -0000 This is a multi-part message in MIME format. --------------22881268F1668A0A10D6DFEB Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit I'll try to propose some text for the ones that would require modifications in the ticket. I assume that is appropriate? Mike On 12/30/20 10:29 AM, Seth Blank wrote: > Thank you filing these tickets. > > With regards to which tickets are actively open, I’ve asked the > document editors to push on open tickets, stand by. > > On Wed, Dec 30, 2020 at 10:21 Michael Thomas > wrote: > > > On 12/30/20 10:13 AM, Alessandro Vesely wrote: > > On Wed 30/Dec/2020 17:38:29 +0100 Dotzero wrote: > >> And for the second time, that is not a DMARC problem, it is an > >> auth-res problem. > > > > > > Standardizing the result names for dmarc authentication method > is an > > integral part of DMARC specification. > > > > Added ticket 91 > > https://trac.ietf.org/trac/dmarc/ticket/91 > > > > I opened a ticket too which basically says that there should be a > normative Authentication-Results Requirements section in the base > specifications. That was a process error from the very beginning with > auth-res and its weird semi-official status. I don't think it has > ever > been discussed whether it is even a protocol or not as Ned brought up > (opened a ticket on that too). > > Mike > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > > > -- > *Seth Blank*| VP, Standards and New Technologies > *e:*seth@valimail.com > *p:*415.273.8818 > > > This email and all data transmitted with it contains confidential > and/or proprietary information intended solely for the use of > individual(s) authorized to receive it. If you are not an intended and > authorized recipient you are hereby notified of any use, disclosure, > copying or distribution of the information included in this > transmission is prohibited and may be unlawful. Please immediately > notify the sender by replying to this email and then delete it from > your system. > --------------22881268F1668A0A10D6DFEB Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

I'll try to propose some text for the ones that would require modifications in the ticket. I assume that is appropriate?

Mike

On 12/30/20 10:29 AM, Seth Blank wrote:
Thank you filing these tickets.

With regards to which tickets are actively open, I’ve asked the document editors to push on open tickets, stand by.

On Wed, Dec 30, 2020 at 10:21 Michael Thomas <mike@mtcc.com> wrote:

On 12/30/20 10:13 AM, Alessandro Vesely wrote:
> On Wed 30/Dec/2020 17:38:29 +0100 Dotzero wrote:
>> And for the second time, that is not a DMARC problem, it is an
>> auth-res problem.
>
>
> Standardizing the result names for dmarc authentication method is an
> integral part of DMARC specification.
>
> Added ticket 91
> https://trac.ietf.org/trac/dmarc/ticket/91
>
I opened a ticket too which basically says that there should be a
normative Authentication-Results Requirements section in the base
specifications. That was a process error from the very beginning with
auth-res and its weird semi-official status. I don't think it has ever
been discussed whether it is even a protocol or not as Ned brought up
(opened a ticket on that too).

Mike

_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
--
Seth Blank | VP, Standards and New Technologies
p: 415.273.8818


This 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.

--------------22881268F1668A0A10D6DFEB-- From nobody Wed Dec 30 10:34: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 703253A0B3D for ; Wed, 30 Dec 2020 10:34:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.087 X-Spam-Level: X-Spam-Status: No, score=-2.087 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, T_SPF_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=valimail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o-JmU7KrDUwu for ; Wed, 30 Dec 2020 10:34:44 -0800 (PST) Received: from mail-vk1-xa2d.google.com (mail-vk1-xa2d.google.com [IPv6:2607:f8b0:4864:20::a2d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 769363A0B37 for ; Wed, 30 Dec 2020 10:34:44 -0800 (PST) Received: by mail-vk1-xa2d.google.com with SMTP id v3so3824475vkb.1 for ; Wed, 30 Dec 2020 10:34:44 -0800 (PST) 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=Cjpnjk2P5LcQ6q/2RZf7zevforwhix1jay8k6yVJrzY=; b=Pengn0oY2+jI63v7XYsXVemTEoV7q82N2trss6oMbtKGRTu0q0my/CouocoSSuX1jo 5bT1BNIAdxHv2at3xhgW3BBQG6C+XzCBI0PIXC+eNmxdM1w1MbtznEW9OLwp0D72LdTy f14fKK04wfSqY+2Ykj2mL66zQ9rHHPmLZR3KniXlhPqqkkMTZu5sj2xo28y0UtXlrA0b EbOE8ShXwkQhpA7uYCKidoCb/uuBm5AJQ15A8jTe7HVSpBjN48G9P5IPdGM+9MwfIMoA br+ZmZ4JmCVdOctwz7NrgBPl2RX1PUsLem2JcMfG5oByxRkk374mTRqHgAVaJlFP0Gqb osIg== 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=Cjpnjk2P5LcQ6q/2RZf7zevforwhix1jay8k6yVJrzY=; b=sIXGABN5Tt041GxPLH0mlS5cbwxjcNfhqgFfKhPLDbG3XiihkEsuctuMGGYyh1qhJy 60k2+fOoXy0cgsqtPm5gNiCoo7VJ25ZRmuCvwD/g0Y/2TvE7W7Kj0src0NxVK8vzj2Ds A5IyrX5wT5wQ2fVlqIcLEdOq3qWSL6Tm6Si0jVbIbqGWgJRXi6hr/hI1I2BYBw2Uy25N j0i4arorGCKzblTCSLyYHkNFk/s4kP15PC0sxeAjMpcYfSYoWPkmKD9htw99brvCBzTX KzOkL1+wSt1n5ohyMAIbv2ijspqhIbxsJ5KZPAUd63KjPcmxLLFDQ+6ZQ6XGL6bdrCo5 X2jw== X-Gm-Message-State: AOAM533wBPASU4fqfB5W1xS53t3nQhSrzf3M1cohHfFk8A9tc6wDKH8Y ZuTm9Nc+JB/QB6gHI529ws8Yy2oNrSFApTeuUyEkZQ== X-Google-Smtp-Source: ABdhPJyHLE+cfZqphTX+In6z7qE527AA+OTl5EhjWIs+uOYZFxPxmSy6uE+fuGsEEybKc0nR7KiVDvrTlgmQ6K0yonY= X-Received: by 2002:a1f:dac7:: with SMTP id r190mr35989722vkg.22.1609353283342; Wed, 30 Dec 2020 10:34:43 -0800 (PST) MIME-Version: 1.0 References: <9f6782b1-e85b-1a9c-9151-98feff7e18ea@mtcc.com> <54dd9978-bcd1-6757-ad27-dcef6db6e5f7@mtcc.com> <937f1019-a028-308d-2a0f-1e720fd49dcd@mtcc.com> <72e20c17-e991-e82a-9120-a27097e3ac58@mtcc.com> <7863d250-f56a-1fe1-44ee-fbc7486d48b4@mtcc.com> <502c2363-385c-b90c-a22a-716594967190@mtcc.com> <01fe63df-1960-868a-3351-08a24bb7a9cf@tana.it> <8e1d6a24-17f4-1fa8-d90a-883e3b8e7432@mtcc.com> <6ef89421-4656-143c-c998-2f167be6c302@mtcc.com> In-Reply-To: <6ef89421-4656-143c-c998-2f167be6c302@mtcc.com> From: Seth Blank Date: Wed, 30 Dec 2020 10:34:32 -0800 Message-ID: To: Michael Thomas Cc: dmarc@ietf.org Content-Type: multipart/alternative; boundary="000000000000c5dbe105b7b2c290" Archived-At: Subject: Re: [dmarc-ietf] auth-res vs. dmarc X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Dec 2020 18:34:50 -0000 --000000000000c5dbe105b7b2c290 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Yes, put whatever you think is appropriate in the ticket, including a link from the dmarc archive to this thread, so that when it is reopened the group has appropriate context On Wed, Dec 30, 2020 at 10:31 Michael Thomas wrote: > I'll try to propose some text for the ones that would require > modifications in the ticket. I assume that is appropriate? > > Mike > On 12/30/20 10:29 AM, Seth Blank wrote: > > Thank you filing these tickets. > > With regards to which tickets are actively open, I=E2=80=99ve asked the d= ocument > editors to push on open tickets, stand by. > > On Wed, Dec 30, 2020 at 10:21 Michael Thomas wrote: > >> >> On 12/30/20 10:13 AM, Alessandro Vesely wrote: >> > On Wed 30/Dec/2020 17:38:29 +0100 Dotzero wrote: >> >> And for the second time, that is not a DMARC problem, it is an >> >> auth-res problem. >> > >> > >> > Standardizing the result names for dmarc authentication method is an >> > integral part of DMARC specification. >> > >> > Added ticket 91 >> > https://trac.ietf.org/trac/dmarc/ticket/91 >> > >> I opened a ticket too which basically says that there should be a >> normative Authentication-Results Requirements section in the base >> specifications. That was a process error from the very beginning with >> auth-res and its weird semi-official status. I don't think it has ever >> been discussed whether it is even a protocol or not as Ned brought up >> (opened a ticket on that too). >> >> Mike >> >> _______________________________________________ >> dmarc mailing list >> dmarc@ietf.org >> https://www.ietf.org/mailman/listinfo/dmarc >> > -- > *Seth Blank* | VP, Standards and New Technologies > *e:* seth@valimail.com > *p:* 415.273.8818 > > > This email and all data transmitted with it contains confidential and/or > proprietary information intended solely for the use of individual(s) > authorized to receive it. If you are not an intended and authorized > recipient you are hereby notified of any use, disclosure, copying or > distribution of the information included in this transmission is prohibit= ed > and may be unlawful. Please immediately notify the sender by replying to > this email and then delete it from your system. > > -- *Seth Blank* | VP, Standards and New Technologies *e:* seth@valimail.com *p:* 415.273.8818 This email and all data transmitted with it contains confidential and/or proprietary information intended solely for the use of individual(s) authorized to receive it. If you are not an intended and authorized recipient you are hereby notified of any use, disclosure, copying or distribution of the information included in this transmission is prohibited and may be unlawful. Please immediately notify the sender by replying to this email and then delete it from your system. --000000000000c5dbe105b7b2c290 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Yes, put whatever you think is appropriate in the ticket,= including a link from the dmarc archive to this thread, so that when it is= reopened the group has appropriate context=C2=A0

On Wed, Dec 30, 2020= at 10:31 Michael Thomas <mike@mtcc.com= > wrote:
=20 =20 =20

I'll try to propose some text for the ones that would require modifications in the ticket. I assume that is appropriate?

Mike

On 12/30/20 10:29 AM, Seth Blank wrote:
=20
Thank you filing these tickets.

With regards to which tickets are actively open, I=E2=80=99ve asked the document editors to push on open tickets, st= and by.

On Wed, Dec 30, 2020 at 10:21 Michael Thomas <mike@mtcc.com> wrote:

On 12/30/20 10:13 AM, Alessandro Vesely wrote:
> On Wed 30/Dec/2020 17:38:29 +0100 Dotzero wrote:
>> And for the second time, that is not a DMARC problem, it is an
>> auth-res problem.
>
>
> Standardizing the result names for dmarc authentication method is an
> integral part of DMARC specification.
>
> Added ticket 91
> https://trac.ietf.org/trac/dmarc/ticket/9= 1
>
I opened a ticket too which basically says that there should be a
normative Authentication-Results Requirements section in the base
specifications. That was a process error from the very beginning with
auth-res and its weird semi-official status. I don't think it has ever
been discussed whether it is even a protocol or not as Ned brought up
(opened a ticket on that too).

Mike

_______________________________________________
dmarc mailing list
dmarc@ietf.= org
https://www.ietf.org/mailman/listinfo/dmarc
--
Seth Blank<= /b> | VP, Standards and New Technologies<= /div>
p: 415.273.8818


This email= and all data transmitted with it contains confidential and/or proprietary = information intended solely for the use of individual(s) authorized to rece= ive it. If you are not an intended and authorized recipient you are hereby = notified of any use, disclosure, copying or distribution of the information= included in this transmission is prohibited and may be unlawful. Please im= mediately notify the sender by replying to this email and then delete it fr= om your system.

--

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


<= /p>

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

--000000000000c5dbe105b7b2c290-- From nobody Wed Dec 30 11:10: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 2B4433A0C0F for ; Wed, 30 Dec 2020 11:10:13 -0800 (PST) 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, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 a5jvZOmSp5Pi for ; Wed, 30 Dec 2020 11:10:11 -0800 (PST) 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 826DA3A0C04 for ; Wed, 30 Dec 2020 11:10:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1609355409; bh=WBUUATnfkqbKQncxWucaFpYqvAuEXCk8A2k2PBz1CLk=; l=3227; h=To:References:From:Date:In-Reply-To; b=CNygKeON35qjLkjBl/8YueSTx+THTpGrWQKjsAdOIRdwW03vDqo4LcmcQ8dO0+hrV VzKEqJi/F2ITwcZKoTbgvSS8F0RTt+vVa76MX28H5IdZLPX+WqJ5rPoNnzZZsdJlii 1qE3R7bARl/JhC7jZqow17QA4prahu1Uvv+sIYQX+4lIqtUw/4mcV6n/AVJOn Authentication-Results: tana.it; auth=pass (details omitted) Original-From: Alessandro Vesely 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.000000005FECD091.00006344; Wed, 30 Dec 2020 20:10:09 +0100 To: dmarc@ietf.org References: <9f6782b1-e85b-1a9c-9151-98feff7e18ea@mtcc.com> <140485eb-020f-4406-3f2f-e2c475ea51e5@mtcc.com> <5588dbbe-b876-ed80-c80f-792380e3718f@mtcc.com> <54dd9978-bcd1-6757-ad27-dcef6db6e5f7@mtcc.com> <937f1019-a028-308d-2a0f-1e720fd49dcd@mtcc.com> <72e20c17-e991-e82a-9120-a27097e3ac58@mtcc.com> <7863d250-f56a-1fe1-44ee-fbc7486d48b4@mtcc.com> <5FECB4F6.2020702@isdg.net> From: Alessandro Vesely Message-ID: Date: Wed, 30 Dec 2020 20:10:08 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: <5FECB4F6.2020702@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] auth-res vs. dmarc X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Dec 2020 19:10:13 -0000 On Wed 30/Dec/2020 18:12:22 +0100 Hector Santos wrote: > > Any A-R evaluation looking for the specific DMARC verification bits as part of > its algorithm, but sees none, MUST use the default input and output values for > a domain that lacks a DMARC record.  For DMARC, when no record exist, the > default values are (please confirm, I am going off my > https://secure.winserver.com/public/wcDMARC wizard form values). > > p=none > sp=none > adkim=relaxed > aspf=relaxed > pct=100% > rua=0 > ruf=0 > rf=afrf > ri=86400 > > The dmarc= value SHOULD not be dmarc=fail nor dmarc=pass because no DMARC > record exist.  So if an A-R is written for a non-DMARC domain, it should be > perhaps write: > >   dmarc=unknown author.d=gmail.com signer.d=gmail.com (originating signer); > > or > >   dmarc=none author.d=gmail.com signer.d=gmail.com (originating signer); I like better the latter (except that author.d should be header.from and signer.d is useless as there must be one or more dkim=pass with a matching header.d=gmail.com or spf=pass with matching helo/ mailfrom property.) > Although the dmarc=none could erroneously suggest a DMARC record exist with a > p=none policy Having no record or just "v=DMARC1; p=none;" should be equivalent. ADSP explicitly said so, preferring an existing record with default values for DNS caching performance. IMHO, we're being somewhat fussy by /requiring/ p=none. > when a real policy exist, then a policy= tag used in our A-R, like: > >   dmarc=dkim-fail policy=none author.d=gmail.com signer.d=gmail.com > (originating signer); should be: dmarc=fail policy.dmarc=none The moment that you deploy existing software, using unregistered properties becomes problematic. Reporting the domain where a DMARC record was found might be useful. However, if you want to use it you should register it. I'd suggest dns.zone=gmail.com, as that ptype.property is already registered, albeit for a different method. > which reads: > > The author.d=gmail.com has a DMARC none policy. It has an aligned author and > signer domain, but DMARC failed due to a dkim-fail signature which the A-R dkim > line shows: > >   dkim=fail (DKIM_BODY_HASH_MISMATCH) header.d=gmail.com header.s=20161025 > header.i=gmail.com; Obviously, SPF failed too. It makes little sense to specify all possible failure reason on the A-R line. > I am not suggesting this or no DMARC A-R line should be written when the domain > lacks a DMARC record. > > If a A-R dmarc line is recorded, it should be readable by humans. It should not > erroneously misdirect an A-R evaluator routine when a DMARC does not exist. > Using the comment field SHOULD be reserved for non-standard HUMAN readable > data.  But some of used it to fill in the gaps we wanted A-R for verification > results, i.e. for SPF, the ip name field. > > Overall, I agree, resolving the A-R name space technical issue SHOULD be > resolved in the WG for DMARC-bis. I think it is well worth the effort to define > what we need and then use this for the update up the A-R specs to create a more > common and useful name space to all. Right. Best Ale -- From nobody Wed Dec 30 11:38: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 F24653A0C43 for ; Wed, 30 Dec 2020 11:38:49 -0800 (PST) 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, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 g5tBPnQqRuI9 for ; Wed, 30 Dec 2020 11:38:45 -0800 (PST) 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 980963A0C40 for ; Wed, 30 Dec 2020 11:38:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1609357123; bh=02t+V00tuHb0AD8HV8mYi2TzzhUEeblj/FfWR666UZI=; l=1716; h=To:References:From:Date:In-Reply-To; b=BDle1F7XkyYdKcYo/wN6IbG49NvCOpiRQw/PVC/J4ZtMxyMyZXAtZDvamdZVn/Byg D4Y7oZZEdJZkeJEs51fs/wGV7wur7DG7zKV53dJAS41NZmLL4Og6I9Lpm97teEJSOj sNnj5GjzMCn7/4JS82KUGgMFrzUmAwkD5MN87hoEG8IP55ZPYmz11EsKLy9Fe Authentication-Results: tana.it; auth=pass (details omitted) Original-From: Alessandro Vesely 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.000000005FECD743.0000653D; Wed, 30 Dec 2020 20:38:43 +0100 To: dmarc@ietf.org References: <9f6782b1-e85b-1a9c-9151-98feff7e18ea@mtcc.com> <140485eb-020f-4406-3f2f-e2c475ea51e5@mtcc.com> <5588dbbe-b876-ed80-c80f-792380e3718f@mtcc.com> <54dd9978-bcd1-6757-ad27-dcef6db6e5f7@mtcc.com> <937f1019-a028-308d-2a0f-1e720fd49dcd@mtcc.com> <53A477E1-3FE1-4D84-A930-BBC6AD006C05@wordtothewise.com> <1c25c82e-db21-ba8b-cd56-3978019e32c4@mtcc.com> From: Alessandro Vesely Message-ID: <2717cf5f-bec9-d561-d7f7-ac167dc7ca6f@tana.it> Date: Wed, 30 Dec 2020 20:38:43 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: <1c25c82e-db21-ba8b-cd56-3978019e32c4@mtcc.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] auth-res vs. dmarc X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Dec 2020 19:38:50 -0000 On Wed 30/Dec/2020 16:17:21 +0100 Michael Thomas wrote: > > On 12/30/20 7:06 AM, Laura Atkins wrote: >> The auth-res result posted as an example of DMARC failing earlier in this >> thread: >> Authentication-Results:mx.google.com; >> dkim=passheader.i=@ietf.org header.s=ietf1 header.b=aayvF8Pg; >> dkim=passheader.i=@ietf.org header.s=ietf1 header.b="PwU4/yuQ"; >> dkim=neutral (body hash did not verify)header.i=@mrochek.com header.s=201712 header.b=PRr8Q7Zv; >> spf=pass (google.com: domain ofdmarc-bounces@ietf.org designates 4.31.198.44 as permitted sender)smtp.mailfrom=dmarc-bounces@ietf.org; >> dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=mrochek.com >> The policy statement is right there: p=NONE. >> > No. That is not guaranteed whatsoever. It could say "(eat at Joe's)" and be valid. Correct. However, it could have been: dmarc=fail policy.dmarc=none header.from=mrochek.com where the property meaning is defined as "Evaluated DMARC policy applied/to be applied after policy options including pct: and sp: have been processed. Must be none, quarantine, or reject." That value appears on the IANA page[*] referring to RFC7489 for its definition. However, Section 11.1 of RFC 7489 only mentions the "from" property. IMHO, dmarc=quarantine is more direct than dmarc=fail policy.dmarc=quarantine. In addition, policy.dmarc as a ptype.property pair sounds redundant. Perhaps it should be policy.result, to emphasize that it has been computed after checking pct= and sp= (to be added: np=) and the alignment of header.from with respect to the dns zone where the record was found. Best Ale -- [*] https://www.iana.org/assignments/email-auth/email-auth.xhtml From nobody Wed Dec 30 12:54: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 760A33A08A5 for ; Wed, 30 Dec 2020 12:54:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.85 X-Spam-Level: X-Spam-Status: No, score=-1.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iecc.com header.b=h/5woOQQ; dkim=pass (2048-bit key) header.d=taugh.com header.b=HSFDt0wZ Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rxOg2-IH6gI0 for ; Wed, 30 Dec 2020 12:54:36 -0800 (PST) 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 9658F3A08A9 for ; Wed, 30 Dec 2020 12:54:34 -0800 (PST) Received: (qmail 3722 invoked from network); 30 Dec 2020 20:54:32 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=e82.5fece908.k2012; bh=8vsMesgjo2SO+wTc8KpNY7dbuF4FgOu+i7fJ2oUKHeQ=; b=h/5woOQQ5Iy5gzS+Q0kThaHqUKkjQRZX5P6SdTVL314mo5Ykv3Kj+r8rTBK/dWO4GA0CLh/gnEoNbeOX3YYl9lxizE3kIxQ0o7GdceMMyzgyQcA3KqdHKCzg4nuuU2ENXgNbeWKV+t9tGP4f+lm0zvcVxu3FJHJNoElE4ndQoDmwQB1sISeTo9H9QSmTN59Za78KH3ECTwqQ6tkcUUSqbHvmoIgdiTNZh7DAEM2+p30ioPzSfcbaWN45A2YtWcUER7Kh4FGgEMuQWJoYxPfd//lzWydEArkoUZeLnRLMPg/Su3fbyBIDRiGLMP5TL+b6CCLZdMduL/xkgoNfeRS/lA== DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=e82.5fece908.k2012; bh=8vsMesgjo2SO+wTc8KpNY7dbuF4FgOu+i7fJ2oUKHeQ=; b=HSFDt0wZsUUjbIqoiih5QNcIW47fHRKy+1CPJBrLJ1JclaqnmFtxK6nGbz6KXcOjh1Ta/66IyfPQXoR22D+ATOP7XZ7PwdAcJ87G2vVAoTve074Rup3L6MZeOqQFsNF5d0IumDBh8ub9/suUlvQCW3hI5fIvOly/CMaKboEoNOOJYyBaagAG7jAsXHyzmayQBBmqOw8PajZJCrg4FTtIvZ5euoaSvln4HXdeh4y7rKtArXbvQZnMxTmwWlJL0RgPdx7TdqD+j7DF9rTjK57uyLE/0HDn8/nXMVVdyaFT3djrYFlcXqhDm1ADZIz92VFgnU72JL9+mIT9DEPmwosPmQ== 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; 30 Dec 2020 20:54:32 -0000 Received: by ary.qy (Postfix, from userid 501) id F03C83AA0126; Wed, 30 Dec 2020 15:54:31 -0500 (EST) Date: 30 Dec 2020 15:54:31 -0500 Message-Id: <20201230205431.F03C83AA0126@ary.qy> From: "John Levine" To: dmarc@ietf.org Cc: vesely@tana.it In-Reply-To: <2717cf5f-bec9-d561-d7f7-ac167dc7ca6f@tana.it> Organization: Taughannock Networks X-Headerized: yes Cleverness: minimal Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] auth-res vs. dmarc X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Dec 2020 20:54:38 -0000 In article <2717cf5f-bec9-d561-d7f7-ac167dc7ca6f@tana.it> you write: >>> dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=mrochek.com >>> The policy statement is right there: p=NONE. >>> >> No. That is not guaranteed whatsoever. It could say "(eat at Joe's)" and be valid. > > >Correct. However, it could have been: > > dmarc=fail policy.dmarc=none header.from=mrochek.com Ticket #86 already suggests we define a few more items to put in a DMARC A-R clause so we don't have to try and guess them from comments. R's, John From nobody Wed Dec 30 13:06: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 998463A00D9 for ; Wed, 30 Dec 2020 13:06:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.85 X-Spam-Level: X-Spam-Status: No, score=-1.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iecc.com header.b=Vw9xlWeF; dkim=pass (2048-bit key) header.d=taugh.com header.b=GnyODjw7 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G13852WsFPRX for ; Wed, 30 Dec 2020 13:06:03 -0800 (PST) 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 4B2F63A00D3 for ; Wed, 30 Dec 2020 13:06:02 -0800 (PST) Received: (qmail 12293 invoked by uid 100); 30 Dec 2020 21:06:02 -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:cleverness; s=2ffa.5fecebba.k2012; i=johnl@user.iecc.com; bh=sU/+wv67JHomfJWLO2BrVO+4PYv4HHhCziRiICR4o2U=; b=Vw9xlWeF+SU0ePmTQfvzmnvu25Y8UCnIeZIwnBTM0x+6iByZt7KKnrl1kErjrMGM6OXcN3JyBeq/MVj/BRLcglCKvFXM9MW5JxTj3F57wBWFRKw2V2nav7ZP/em40HWtBS0DIHgYt/YXorMQkeFYs8YA3kq49Mzzp+2/6Ole1KWDklR9IWvKJ8BjF37TanX6wE0I0fDCVzGRcXtKTYFOzb8aG8mfGOyl7waz3vQcPiPdZoGyGmEyYMWWOAXuCzNonfDdrg009SyscJ5QKqx39Q21m8PBr4pUVODwDix+naxYF/+M5njZTTjNbzQhcjMsy4vYKIKI+tATQe20y9IJKA== 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:cleverness; s=2ffa.5fecebba.k2012; olt=johnl@user.iecc.com; bh=sU/+wv67JHomfJWLO2BrVO+4PYv4HHhCziRiICR4o2U=; b=GnyODjw78ypjs+JHmlP4zQwAMPtoWErVVZ+JCFq1O8mqUeVAuu2sbqmKXSzJXImPGcARZzSGtnfmjBcezrewxxZ9EuTbKFKLjnvHDf2QkKRAU5oZl9h2OCER5utQavyZdCi6fu2QHtRMWfdoJwiBH/uV8gsrMHjPuf8nZ0EB1sfsLaNf0XwKzcUqM2/+7nFhxsv3kDVTgWtG/jFtlK0ltiWJytR230pazMlQFgI9Jy2QtceHQJeHZHAUDl2RF+qHiKAZVhUsUtLrdadL0oCh9BOGRDIy2sbIsnziOyueQ9QLP/QIRBwll7rWhkVFkpaFlliyh1UgkTqJotLA43SC5A== Date: 30 Dec 2020 16:06:01 -0500 Message-ID: <45b3df7-5c6-9744-2ca8-1542e1b33e7b@taugh.com> From: "John R Levine" To: dmarc@ietf.org In-Reply-To: References: Cleverness: None detected MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="3168237118-343771159-1609362361=:5427" Archived-At: Subject: Re: [dmarc-ietf] Ticket #1 - SPF alignment X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 30 Dec 2020 21:06:07 -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. --3168237118-343771159-1609362361=:5427 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE > We would like to close this ticket by Dec 15, two weeks from now, so shor= t=20 > trenchant comments are welcome. > > Ticket #1 is about SPF alignment. We need to replace references to 4408 = with=20 > 7408, ando clarify what if anything we do with SPF HELO checks if > the MAIL FROM is null. One possibility is to say only MAIL FROM SPF coun= ts,=20 > if you want to align your bounces, sign them. The other is to explicitly= say=20 > that HELO alignment is OK on bounces. I didn't hear a lot of strong opinions, but I think they leaned in the=20 direction of only checking the MAIL FROM, since the name of the MTA often= =20 is unrelated to the From: domain. This means that if you want your bounces to be DMARC aligned, they'd need= =20 DKIM signatures. R's, John > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > From: Anne Bennett > Date: Fri, 16 Jan 2015 19:10:56 -0500 > Subject: [dmarc-ietf] SPF RFC 4408 vs 7208 > > On Jan 6, Murray S. Kucherawy confirmed fixing the reference for > the SPF RFC from the now-obsolete 4408 to 7208 ("Fixed in -11"). > However, -12 still has, in section "3.1. Identifier Alignment": > For example, [DKIM] authenticates the domain that affixed a > signature to the message, while [SPF] authenticates either > the domain that appears in the RFC5321.MailFrom? portion of > [SMTP] or the RFC5321.EHLO/HELO domain if the RFC5321.MailFrom? > is null (in the case of Delivery Status Notifications). > Actually, RFC 7208 states that: > Checking "HELO" before "MAIL FROM" is the RECOMMENDED sequence > if both are checked. > > ... and implies that if the first check passes, the second > is unnecessary: > > If a conclusive determination about the message can be made > based on a check of "HELO", then the use of DNS resources to > process the typically more complex "MAIL FROM" can be avoided. > So the RFC5321.EHLO/HELO domain is checked not only if the > RFC5321.MailFrom? is null - in fact in cases where sites have > followed the RFC 7208 recommendation, it will be checked first, > at least by a "pure SPF" implementation. > This means, first of all, that the -12 text above needs fixing. > But also, I'm struggling with what it means for alignment. > I can think of some real-life cases where only one of > HELO or MAIL FROM aligns with RFC5322.From, even though > both would "pass" in a pure SPF check. IMHO, Section > "3.1.2. SPF-authenticated Identifiers" needs to be clarified > to better take HELO into account. > I'd like to see an approach similar to that for DKIM, where it > is explicitly stated that: > a single email can contain multiple DKIM signatures, and it > is considered to be a DMARC "pass" if any DKIM signature is > aligned and verifies. > Similarly, I think that for SPF, it should be considered a pass > if either the MAIL FROM or the HELO is aligned and results in a > pass at the SPF level. > But whether it is decided to take into account both HELO and MAIL > FROM, or whether it is decided to ignore HELO (modulo its use to > construct an artificial MAIL FROM if the latter is null), the text > should IMHO make this clear one way or another, both in "3.1.2. > SPF-authenticated Identifiers": > In relaxed mode, the [SPF]-authenticated domain and > RFC5322.From domain must have the same Organizational Domain. > In strict mode, only an exact DNS domain match is considered > to produce identifier alignment. > > ... and in "4.1. Authentication Mechanisms": > > o [SPF], which authenticates the domain found in an > [SMTP] MAIL command when it is the authorized domain. > In both cases, the text should specifically mention HELO, > and whether to include or exclude a HELO SPF result, in view > of HELO's prominence in RFC 7208. > If it is decided to allow both HELO and MAIL FROM results to be > passed back to DMARC, then in section "6.6.2. Determine Handling > Policy", item 4 should be updated to reflect that as well. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY "I dropped the toothpaste", said Tom, crestfallenly. --3168237118-343771159-1609362361=:5427-- From nobody Wed Dec 30 13:18: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 889973A0147 for ; Wed, 30 Dec 2020 13:18:06 -0800 (PST) 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 (2048-bit key) header.d=iecc.com header.b=NMligjbN; dkim=pass (2048-bit key) header.d=taugh.com header.b=nX/fjOPX Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3nd7l6IF7jUy for ; Wed, 30 Dec 2020 13:18:05 -0800 (PST) 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 ECAD03A0140 for ; Wed, 30 Dec 2020 13:18:04 -0800 (PST) Received: (qmail 32609 invoked from network); 30 Dec 2020 21:18:03 -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:cleverness; s=7f5c.5fecee8b.k2012; i=johnl-iecc.com@submit.iecc.com; bh=YKXh0D+TpM8q6Zmu/e0b1uqZQdSo+6kR4PjnWvOGtVc=; b=NMligjbNAMmVYo62HSjEms85S+SlZf0ohEdt79YSrSEfZhXN3dUBw8S6tc08yCwCdw1nidgUW5cuuHkJGKQilNLJ4jqbSm49vgBCk/XBBso4xxl7Mh87cdFbRU2kM1MV8UiBnuQZtv3Ma9xyWtmXUptj2XNk6zZ8TGF23incico8zcspPriZpU2rlI978bmY0AYLuUALpPe73ZcDDka/iC8c5hMNHGPfJsDwmL0b0d2iJdoj7AQ52VvjQFRWJ9/ZXqS+oEIWOwN6b7Ewypvrl3esBqE4MuSnh4X1NvZJOvO/9zUjihVc7l8XKK+qEXte057c2rnOQyqqhggUuGgFHA== 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:cleverness; s=7f5c.5fecee8b.k2012; olt=johnl-iecc.com@submit.iecc.com; bh=YKXh0D+TpM8q6Zmu/e0b1uqZQdSo+6kR4PjnWvOGtVc=; b=nX/fjOPXk0ifXk5H5+bUpgv1i9OIY7sS4R4Eqi7xKyZRIipprtnQ+NmjYUoIiORqaD6U0g0Kb58qzxIPM0CDRCI6PB+YwX87gTQ86LZ82hzT59cSOsisw94EkucBIf0KHRyFYmD40oRi4kgojx44qflbUkng7I5MsvJOSTV5VBLCutINCQCVD9APYDGBzHrJ+loWibl9tm1c03gKwzk9Qu0s5vib/jI40UfLZp+Q849Q99h4u5BcuZ+ZAXRiQSKKH7Uy3HffUmpUowlMSRdEXGRuommNOarueffZKGbGVHVaiHQlMHe1xY/ybnamcjsjpx1UutCXexXLbSY+/3eixQ== 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; 30 Dec 2020 21:18:03 -0000 Date: 30 Dec 2020 16:17:47 -0500 Message-ID: From: "John R Levine" To: dmarc@ietf.org In-Reply-To: <20201204195833.6B48A28F892A@ary.qy> References: <20201204195833.6B48A28F892A@ary.qy> Cleverness: None detected MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII Archived-At: Subject: Re: [dmarc-ietf] Ticket #28 - Failure report mail loops X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Dec 2020 21:18:07 -0000 On Fri, 4 Dec 2020, John Levine wrote: > In article <0408ae98-e1c1-71fe-fdd4-8bc7a7c151d3@tana.it> you write: >> We would like to close this ticket by Dec 18, two weeks from now, so please get >> on it. >> >> The ticket originated from John's comment, in May 2019: >> >> Apropos recent discussions, we could recommend that failure reports be >> rate limited per recipient both to break loops and to deter indirect >> mail bombing. > > I have never gotten enough failure reports that handling them was even > slightly inconvenient, and my addresses are on every spam list in the world. > > Has anyone else? If don't have evidence that this is a real problem, I'd just close the ticket. The answer was apparently no, so I propose we close this with no change. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY "I dropped the toothpaste", said Tom, crestfallenly. From nobody Wed Dec 30 13:23: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 EF39C3A086D for ; Wed, 30 Dec 2020 13:23:24 -0800 (PST) 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 (2048-bit key) header.d=iecc.com header.b=Z4i9uuEj; dkim=pass (2048-bit key) header.d=taugh.com header.b=mddpFHQw Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iOBNJGzFhR7O for ; Wed, 30 Dec 2020 13:23:23 -0800 (PST) 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 F0AE03A0825 for ; Wed, 30 Dec 2020 13:23:22 -0800 (PST) Received: (qmail 34143 invoked from network); 30 Dec 2020 21:23:21 -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:cleverness; s=855b.5fecefc9.k2012; i=johnl-iecc.com@submit.iecc.com; bh=mm17nrjckXXGrIQhoNdtgK2grwBRftH599ZJLqbiYdo=; b=Z4i9uuEjPVaod/++qOa61AJ1lQq7s6k868W7BaXwvHqhr0o6rmmswVda5zWibi+a/0WWks1X/d0i0GzShOypLSr/2eUq1vXzsQJPkjXjUqXB67wDr4XKN7MeilG8MqlIdmyxmNKuvxj/EaTAXbnYpmlkbgOSfXfPTgM9xf7cqdBIH7is/Z2oWhaRnfoyIQm+PQ97RrJeql6gpr26IxqD2HZVvH2Yev1VjE2Vhlf/fqK3Zf1kRb/8CJPVSEj8PnSuFBraw00cC6DOgxwhaSMmfCjmuHhezwF8RuYrUe4tGPz4EtieIeJa/6qvK1RKzR79w/9LXgA377GX/n3bEdvmPA== 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:cleverness; s=855b.5fecefc9.k2012; olt=johnl-iecc.com@submit.iecc.com; bh=mm17nrjckXXGrIQhoNdtgK2grwBRftH599ZJLqbiYdo=; b=mddpFHQwvcYOBEy6EFzelLQ8BkEdTlMpI3NF3eDpFW1bPx4EmSi/pvad780WcE7Lw0CRUrvTR7JBOCRZoKOHaYsyl7vdJc8ob3molmlnKN5Q4aMCIbVnZxw8cx7i0LNZAIWdWEKcCGiimicQqpjAInEIhMvNL0t6gTncAYM04LindtwqFw2mCPUyex73S3mZSM2oAFNVUuObYadfPTR1X7cSvv+LSn8bn0AjuV13ClsSmse4SOWdWS6atFmupYcHryqvhKpVQl9f/yywTHyTyswTlQQKpq444iEoBWgd2ztH3a05BfQ2RsrH2ryhGZlSdoANQDxeroryfgQY9l6Npg== 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; 30 Dec 2020 21:23:21 -0000 Date: 30 Dec 2020 16:23:20 -0500 Message-ID: From: "John R Levine" To: dmarc@ietf.org In-Reply-To: References: Cleverness: None detected MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII Archived-At: Subject: Re: [dmarc-ietf] Ticket #42 - Expand DMARC reporting URI functionality X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 30 Dec 2020 21:23:25 -0000 > We would like to close this ticket by Dec 15, two weeks from now, so short > trenchant comments are welcome. > > Ticket #1 is about https reporting. Early drafts of the DMARC spec had a > poorly defined http report which we took out. I propose we add back https > reporting similar to that for mta-sts, with a POST of the gzipped report to > the HTTPS URI. I still think that reporting by POST is a swell idea, since it's considerably faster and more secure than e-mail for large reports. (There's no attachments or base64 coding, and the report goes direct to the recipient server, no mail relays or possible misrouting or bounces.) There was some discussion about the detail that if there are multiple addresses in the rua= tag you send the report to all of them. People were quite clear that is a feature. I proposed as a hack a ruap= tag for rua preferred, if the reporting system can send reports to all of the URIs in the ruap tag it does so, otherwise it uses rua as it does now. That lets you put the https URIs in the ruap tag which existing code will ignore. Didn't get a lot of comments pro or con on that one. R's, John > We can adapt the approach MTA-STS uses in RFC 8460. > > If rua= has an https URI, the reporter uses HTTP POST to that URI with > the report as an uncompressed or gzipped XML file as the POST body. > The media type is the same as is used in mail reports, application/xml > or application/gzip. Reports SHOULD be gzipped. If we keep the !size > hack, they MUST be no larger than the size limit. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY "I dropped the toothpaste", said Tom, crestfallenly. From nobody Wed Dec 30 13:49: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 766C83A0965; Wed, 30 Dec 2020 13:49:27 -0800 (PST) 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, HTTPS_HTTP_MISMATCH=0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id exnfm6C70eRP; Wed, 30 Dec 2020 13:49:23 -0800 (PST) Received: from mx0a-00143702.pphosted.com (mx0a-00143702.pphosted.com [148.163.145.77]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C0573A0940; Wed, 30 Dec 2020 13:49:20 -0800 (PST) Received: from pps.filterd (m0184893.ppops.net [127.0.0.1]) by mx0a-00143702.pphosted.com (8.16.0.43/8.16.0.43) with SMTP id 0BULbfoM028716; Wed, 30 Dec 2020 16:49:19 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=20190412; bh=FT1bN4KFBcjk0mG0DREZGzrGcJiRdm8r4RWuWG07B5A=; b=3tezD1UrfYp1+I4DSQfZgkCMifg/tQcpB5vy/y20kmOFP+P+TgxseFRfM/639SxFDjf3 twJEwwgOk+oubVzCGKmOXJKjKob8B/QhnEC/IR2so8zzg+2NQBB6MWZnMozD+MiRT6C1 Yl8RO8i2qtSknHVbI2rbDrgQOsRX0/GfpBtWOG0gG/5k+085lGrHRsuz49NiI9hNHnGS jW9ioMTrQ17cCeF+YzI2/uoU+zrdY5K/XrcebRC4UBq/HBp4X8h+VJ9tYsy7GqInHvIl IOEL70UEnd3aoVpnUDo1w8ENtGEm/JZqVwDryyVxs0ULlMGrWVWnSXT4oFB5lxuoRDPy Xw== Received: from copdcexc35.cable.comcast.com (dlppfpt-po-1p.slb.comcast.com [96.99.226.137]) by mx0a-00143702.pphosted.com with ESMTP id 35p17mqq6y-2 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 30 Dec 2020 16:49:19 -0500 Received: from copdcexc33.cable.comcast.com (147.191.125.132) by COPDCEXC35.cable.comcast.com (147.191.125.134) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1713.5; Wed, 30 Dec 2020 14:49:17 -0700 Received: from COPDCEXEDGE01.cable.comcast.com (96.114.158.213) by copdcexc33.cable.comcast.com (147.191.125.132) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1713.5 via Frontend Transport; Wed, 30 Dec 2020 14:49:17 -0700 Received: from NAM04-BN3-obe.outbound.protection.outlook.com (104.47.46.55) by webmail.comcast.com (96.114.158.213) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 30 Dec 2020 16:48:58 -0500 Received: from MN2PR11MB4351.namprd11.prod.outlook.com (2603:10b6:208:193::31) by MN2PR11MB4599.namprd11.prod.outlook.com (2603:10b6:208:26d::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3721.20; Wed, 30 Dec 2020 21:48:57 +0000 Received: from MN2PR11MB4351.namprd11.prod.outlook.com ([fe80::7ca6:b482:a6b0:4d42]) by MN2PR11MB4351.namprd11.prod.outlook.com ([fe80::7ca6:b482:a6b0:4d42%7]) with mapi id 15.20.3700.031; Wed, 30 Dec 2020 21:48:57 +0000 From: "Brotman, Alex" To: Emil Gustafsson CC: Marc Bradshaw , DMARC IETF Thread-Topic: [dmarc-ietf] Discussion - ARC/Extensible Reporting (Ticket #56) Thread-Index: AdbI4+CbIMDOrFacSCuqUWajtLQ8TwAgvwMAAA97pBAAAfRzAADOhtAAAC42nxAC8UhBgAAllgIA Date: Wed, 30 Dec 2020 21:48:57 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: dmarc.ietf.org; dkim=none (message not signed) header.d=none; dmarc.ietf.org; dmarc=none action=none header.from=comcast.com; x-originating-ip: [2601:43:101:380:2423:843e:71e9:c926] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: db23ed25-6ac1-4efd-c0fe-08d8ad0cb5e8 x-ms-traffictypediagnostic: MN2PR11MB4599: 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: ciGU7oiKcD5UZfXe7Hu7xL/UsTv74hf56uoAOYgNjvcELGe32XjlPuznLT2C16JwzajPE6AKcp3G89EG9sQYg3Zuw61cTVJaeyz00soomGs5i92elZLob3zDM/iBl7aiRmc+PcVhCI+jXYXDlmDNymbLveZCp4ZM1omhB1LMoH/F0m/sclfjtktF0TMC+9ciDXtUeg0VA4WipXdgUgWjTkO0gACN30RihzMffSoqeHtRzpbL6IgARWgOoVELyWfp+1jovnEB+nnY4hdSmOhBotTYybDn+dSc2ycxdeHIQZMV4BGHH+fPx2dO7nhu6oKB5jBf9lKxJMwIUjGtKg9EwNG8QOWaP/cpMYLE2c7UaC0CGSsuLUqRNhHpSQJGlxzb6/RDj9xcsJuKKznhOo9fhULrPMYbAetEfzdh0aIyXffziZPyCVVelBl3VaW4ST+Hh6Zu6kUN2CgmYwZOsNVQ4w== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR11MB4351.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(346002)(366004)(396003)(376002)(136003)(39860400002)(86362001)(316002)(33656002)(54906003)(71200400001)(99936003)(52536014)(478600001)(6506007)(53546011)(2906002)(66946007)(8676002)(66556008)(966005)(66446008)(66616009)(8936002)(5660300002)(66476007)(64756008)(76116006)(55016002)(9686003)(83380400001)(166002)(186003)(4326008)(7696005); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: =?utf-8?B?VjhCOERkSmFnQ0dlRk1UWloveVJteWxDMGpLRmNkbys5NEQzYm9MTGFiZ3Vi?= =?utf-8?B?c3o4L0JkWVQ2c3RLcGJabFBRdDRXa3NPcCtGRDhyS09aVExMK2Z3Y1h0REtR?= =?utf-8?B?Q0NPK3RudnBxMG93ZmtVY3pIcEZzSXZzbW44ZXhwd2s3V0xkMnR2eld6cmt0?= =?utf-8?B?OHlnaERnTHBaOU4zVnpFRXMzUzdNbk9LRis0WHd0QzVydmduQUNwNkJjTFZZ?= =?utf-8?B?aGxhOWJCcjFvVFdXQ042MGNQdXg2QkZjT1pnUFlvMnV0OHFxWEEwZGlrWkY1?= =?utf-8?B?NnBsOTB4MTFuSERxNHRHWXMyZkRnOFVIbXJpTjEzdThrMHRoYlhtdlJ4K245?= =?utf-8?B?K2c3V1VEK2twenNMSTVyQzBDQ3hyZ2JpZzlxcjJwWDRNMXFlQTkyZDltZkE5?= =?utf-8?B?NEVqTU5ZQ1FWVHYwVklUNDIzYzZUQ0hwVml6V0ZGZTJid0JMdWJkUHB0VE53?= =?utf-8?B?Zm5LMTNkQVVFdDJuTlQ5R2hkajBESGUwRUdFTHR0c2pqdEFrajNOeVFpL2xZ?= =?utf-8?B?UDlWWHpTMjhJazFxdkdsYXJWOGxhVnNLaVYzZ2VIMGZaWGZOK3EyM3BUdmJw?= =?utf-8?B?bUg4UUtjMFJKR010TmNPdnlmTlV5TGw1a2lvY2Uyb2R6ZWNtNFRZVzk1S2ZK?= =?utf-8?B?Y2VqaEpGckRvSDgwZ2QwMHhkZktFdXFiNGJoQzVjVmtRNXBSTHp5QmQ3ZXJB?= =?utf-8?B?N0VjMVJCWUhFUEdLTTFMcWxkTTlFNWVEMG1CZThKeG1uVnJnNFRXTTMzTHZT?= =?utf-8?B?T2Qyd1VuNER5QUNrekhBcU5idW9FV3RFR3hZeXFnc2ViSVRPTHlKWkFjMGJB?= =?utf-8?B?VUs2RGJSOUxtZ2c5VENqb1YvdlpDQ1NxZFRoMDk3ckVuUHN4ZFQ4Vy9jenM0?= =?utf-8?B?a3RkazhiUGRQY2VBS2VicW5jNzNhYTNOS1RBQXdxQ1RuQXZRSmoycUpCa1Rj?= =?utf-8?B?WUhGWHpBR3B5NWs0N29XTVpSSWppUjRJdUMrdDRUQllkaVFIbU50WmJURUhN?= =?utf-8?B?c2s0bEtMc2l2OVZQK1BwVTk0TTZlRHNobHliQTFYbmZXaHQ4WW0wbkxEbUxX?= =?utf-8?B?SVZVckcxT2NvR0dwZDFvbzAxZ1MramFFWDZqU05SQytycDVWdHQwWEpLYm1m?= =?utf-8?B?ZDRFa2hpZldGVFJGb01HNjJRTFNxMW92VS9HYWNFL0dvaGh5TW5aOEx1MnlL?= =?utf-8?B?eVM4c0VSRkhlU0h1UFIva0hDMGUxdjVPNUhBZElEK3h4Q0FNODdaMVA0VWUv?= =?utf-8?B?RCtBd2ZQZmlNV0l4MktTbUw2eWxGN3g5T0hBemhKMjVMK1QrUnpFT05oQ0JV?= =?utf-8?B?U0hMR1FtVmRzbm9vaithM2RWeG1TM1R3SW1hc3I2bk9XaEEwam1wL3g0b0sz?= =?utf-8?Q?5037rEcoPL89+wdKGDB9VOKCoeQQv0J8=3D?= x-ms-exchange-transport-forked: True arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=DmfnGGNqfnmxkBahV7MLgCxGpGaZ++6aNatb8DEl/Nk5JIv2lpRIC2gn5PsbdU1YoCOTm4cdRhEH4z+dFNXyuKOFE9zp8B1h6degeCWbGGhRN6wnyaOPQAuxVOWVEwC8ym7m5pZ98Mwj9DaxXSAaGEIQWc49G5ZY2JlQBCLb2P7dCiw+cF3dVSk7kFOktzTCYODuXEiMP9Y+Wl7CbbtOJmcRsriy+ApOF+TZjYUQg5CtT8EmSXozuac93aefb0FY0tfYUj+kWxmvD5juFx15c0c1hozCIiGUUZoMtpD594WYmEr7pu2PKjryevCzyGkRzArm45AUQ6j3Hc8CX+H/kA== 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=aYclLy4luQrVNO+jeWflu/Drp6tPcVzfNe+qNmeAAPI=; b=oCV3B35oxxEc7oaw0yNWv7UTWv4kI3q2/iG9blmtFxJKEaCUy1eaGIg5OFs4P21nAWuPFjbniLarE9AKILAw5hBnrY9FQG1+D5VTog6ppSnWBA4H/H7n0JcCTIjo3QwNKTeAOEjFL3G4eTGpdUGhohgb/0mnt3SaF53iELh9LY+YJ0YSZ+qma94X0G9S31tjXEkrjJ1rijch5Js/edzdl0DKoE7pz47jF4B1AA7PaCfOrdgJ6YMev69frfYlPBiIxbBgVJIMY6w3yZmLWPUPy4yVp73YcUe78JaN85/RgNPNxg6OZki2K0owg3gBANHcMfQOtrv2jhjS/ddneF51Ew== arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=comcast.com; dmarc=pass action=none header.from=comcast.com; dkim=pass header.d=comcast.com; arc=none x-ms-exchange-crosstenant-authas: Internal x-ms-exchange-crosstenant-authsource: MN2PR11MB4351.namprd11.prod.outlook.com x-ms-exchange-crosstenant-network-message-id: db23ed25-6ac1-4efd-c0fe-08d8ad0cb5e8 x-ms-exchange-crosstenant-originalarrivaltime: 30 Dec 2020 21:48:57.5278 (UTC) x-ms-exchange-crosstenant-fromentityheader: Hosted x-ms-exchange-crosstenant-id: 906aefe9-76a7-4f65-b82d-5ec20775d5aa x-ms-exchange-crosstenant-mailboxtype: HOSTED x-ms-exchange-crosstenant-userprincipalname: Z/iPqXE/mNkaO1xcTwiRFYq2RqVKoNhlRpQZLLdEvK8vMs5N2chG4N+I72xGbNi+pxKI5LnweMC1MJ0XXW7kOqELq6LZplvMrUQOKPBd8e4= x-ms-exchange-transport-crosstenantheadersstamped: MN2PR11MB4599 x-originatororg: comcast.com Content-Type: multipart/related; boundary="_004_MN2PR11MB43518DB46CF9F6C5A6080C65F7D70MN2PR11MB4351namp_"; type="multipart/alternative" MIME-Version: 1.0 X-CFilter-Loop: Forward AAETWT X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.343, 18.0.737 definitions=2020-12-30_14:2020-12-30, 2020-12-30 signatures=0 X-Proofpoint-Spam-Reason: safe Archived-At: Subject: Re: [dmarc-ietf] Discussion - ARC/Extensible Reporting (Ticket #56) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 30 Dec 2020 21:49:28 -0000 --_004_MN2PR11MB43518DB46CF9F6C5A6080C65F7D70MN2PR11MB4351namp_ Content-Type: multipart/alternative; boundary="_000_MN2PR11MB43518DB46CF9F6C5A6080C65F7D70MN2PR11MB4351namp_" --_000_MN2PR11MB43518DB46CF9F6C5A6080C65F7D70MN2PR11MB4351namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpXZeKAmXZlIGFscmVhZHkgbWVudGlvbmVkIEFSQy4gIENvdWxkIGl0IGFsc28gYmUgZXh0ZW5k ZWQgdG8gYWxsb3cgZm9yIERvbWFpbiBSZXB1dGF0aW9uIHJlcG9ydGluZyBiYWNrIHRvIHRoZSBz ZW5kZXI/ICBJbnN0ZWFkIG9mIGEgY2VudHJhbCBhY2Nlc3MgcG9pbnQsIHRoZSBkYXRhIGlzIHNl bnQgcGVyaW9kaWNhbGx5IHRvIHRoZSBkb21haW4gaG9sZGVyLCBhbmQgdGhleSBjYW4gdGhlbiB1 dGlsaXplIHRoZSBkYXRhIGFzIHRoZXkgc2VlIGZpdC4gIEkgY291bGQgYWxzbyBzZWUgYSB1c2Ug Y2FzZSBmb3IgQklNSSByZXBvcnRpbmcuICBJ4oCZbSBzdXJlIG90aGVycyBjb3VsZCB0aGluayBv ZiBvdGhlciB1c2UgY2FzZXMuDQoNCklmIHdlIHByZWZlciBpdCB0byBleGlzdCBvdXRzaWRlIG9m IHRoZSBtYWluIGJvZHkgb2YgZGF0YSwgaXQgbWF5IHJlc3VsdCBpbiBkdXBsaWNhdGlvbiBvZiBk YXRhLCBidXQgYWxzbyBhbGxvd3MgZm9yIG1vcmUgZmxleGliaWxpdHkuIFRoaXMgYWxsb3dzIHRo ZSBvcmlnaW5hbCBETUFSQyBBZ2dyZWdhdGUgZGF0YSB0byByZW1haW4gY29uc2lzdGVudCBhcyB3 ZWxsLiAgT24gdGhlIG90aGVyIGhhbmQsIGFsbG93aW5nIGl0IHRvIGV4aXN0IHdpdGhpbiB0aGUg cmVjb3JkIGVsZW1lbnRzIHdvdWxkIGFsbG93IGl0IHRvIGJlIG1vcmUgZWFzaWx5IGNvcnJlbGF0 ZWQgd2l0aCB0aGUgZXhpc3RpbmcgZGF0YS4gIEkgdGhpbmsgbXkgKHNsaWdodCkgcHJlZmVyZW5j ZSAoYXMgYSByZXBvcnQgaGFuZGxlcikgaXMgdG8gaGF2ZSBpdCBvdXRzaWRlIG9mIHRoZSBtYWlu IGJvZHkgb2YgdGhlIHJlcG9ydCwgYnV0IEkgY291bGQgYmUgc3dheWVkLg0KDQoNCi0tDQpBbGV4 IEJyb3RtYW4NClNyLiBFbmdpbmVlciwgQW50aS1BYnVzZSAmIE1lc3NhZ2luZyBQb2xpY3kNCkNv bWNhc3QNCg0KRnJvbTogRW1pbCBHdXN0YWZzc29uIDxlbWd1PTQwZ29vZ2xlLmNvbUBkbWFyYy5p ZXRmLm9yZz4NClNlbnQ6IFdlZG5lc2RheSwgRGVjZW1iZXIgMjMsIDIwMjAgMjo0OSBQTQ0KVG86 IEJyb3RtYW4sIEFsZXggPEFsZXhfQnJvdG1hbkBjb21jYXN0LmNvbT4NCkNjOiBNYXJjIEJyYWRz aGF3IDxtYXJjQG1hcmNicmFkc2hhdy5uZXQ+OyBETUFSQyBJRVRGIDxkbWFyY0BpZXRmLm9yZz4N ClN1YmplY3Q6IFJlOiBbZG1hcmMtaWV0Zl0gRGlzY3Vzc2lvbiAtIEFSQy9FeHRlbnNpYmxlIFJl cG9ydGluZyAoVGlja2V0ICM1NikNCg0KV2hpbGUgdGhlIGNvbW1vbiBmb3JtYXQgd291bGQgYmUg Z3JlYXQgYXMgYSBjb25zdW1lciBvZiByZXBvcnRzLCBJJ20gd29uZGVyaW5nIGhvdyBtYW55IGRp ZmZlcmVudCByZXBvcnRzIHRoZXJlIHdvdWxkIGJlLiBOZXcgYXV0aCBzdGFuZGFyZHMgZG9uJ3Qg cG9wIHVwIHRoYXQgb2Z0ZW4sIHNvIHdoYXQgb3RoZXIgcmVwb3J0cyBhcmUgeW91IHRoaW5raW5n IGFib3V0PyBJIGNhbiBzZWUgdHdvIG9idmlvdXMgY2FuZGlkYXRlczsgdGhlIG1haWxzZXJ2ZXIg c29mdHdhcmUgYW5kIHRoZSBzcGFtL2FidXNlIHByZXZlbnRpb24gc29mdHdhcmUuIEl0IHdvdWxk IGJlIGludGVyZXN0aW5nIHRvIHN1cHBvcnQgc29tZXRoaW5nIGxpa2UgdGhhdCB0b28gYnV0IHNo b3VsZG4ndCB0aG9zZSBqdXN0IHB1dCB0aGUgcmVzdWx0cyBpbnNpZGUgdGhlIGRraW0vc3BmL2Fy YyBhdXRoX3Jlc3VsdHM/DQovRQ0KDQpPbiBUdWUsIERlYyA4LCAyMDIwIGF0IDEyOjI5IFBNIEJy b3RtYW4sIEFsZXggPEFsZXhfQnJvdG1hbj00MGNvbWNhc3QuY29tQGRtYXJjLmlldGYub3JnPG1h aWx0bzo0MGNvbWNhc3QuY29tQGRtYXJjLmlldGYub3JnPj4gd3JvdGU6DQpJIGZlZWwgKGFzIGEg cmVjZWl2ZXIgb2YgcmVwb3J0cykgYXMgdGhvdWdoIGFub3RoZXIgcmVhc29uIHRvIGhhdmUgdGhl c2UgYXMgYSBzaW5nbGUgcmVwb3J0IGlzIHNvIHRoYXQgdGhlIHJlY2VpdmVyIG9mIHRoZSByZXBv cnQgaXMgYWJsZSB0byBtb3JlIGVhc2lseSBjb3JyZWxhdGUgdGhlIGRhdGEvdGltZXMuICBJIHNo b3VsZCBiZSBhYmxlIHRvIGJlbGlldmUgdGhhdCBhbGwgcmVwb3J0cyAod2l0aG91dCBhIHNwZWNp ZmllZCByaSkgd2lsbCBiZSAwMDAwLTIzNTksIHRob3VnaCB0aGluZ3MgaGFwcGVuLCBhbmQgc3lz dGVtcyBicmVhayBkb3duLg0KDQotLQ0KQWxleCBCcm90bWFuDQpTci4gRW5naW5lZXIsIEFudGkt QWJ1c2UgJiBNZXNzYWdpbmcgUG9saWN5DQpDb21jYXN0DQoNCkZyb206IGRtYXJjIDxkbWFyYy1i b3VuY2VzQGlldGYub3JnPG1haWx0bzpkbWFyYy1ib3VuY2VzQGlldGYub3JnPj4gT24gQmVoYWxm IE9mIE1hcmMgQnJhZHNoYXcNClNlbnQ6IE1vbmRheSwgRGVjZW1iZXIgNywgMjAyMCA1OjE3IFBN DQpUbzogRE1BUkMgSUVURiA8ZG1hcmNAaWV0Zi5vcmc8bWFpbHRvOmRtYXJjQGlldGYub3JnPj4N ClN1YmplY3Q6IFJlOiBbZG1hcmMtaWV0Zl0gRGlzY3Vzc2lvbiAtIEFSQy9FeHRlbnNpYmxlIFJl cG9ydGluZyAoVGlja2V0ICM1NikNCg0KDQpUaGVyZSBpcyB2YWx1ZSBpbiBpbmNsdWRpbmcgdGhl c2UgaW4gb25lIHJlcG9ydCwgZXNwZWNpYWxseSB3aGVyZSB0aGUgZXh0ZW5kZWQgcHJvcGVydHkg YmVpbmcgcmVwb3J0ZWQgb24gaW5mbHVlbmNlcyBob3cgRE1BUkMgaXMgZXZhbHVhdGVkLg0KDQpV c2luZyBBUkMgYXMgdGhlIGV4YW1wbGUsIHdoZW4gYSBwPXJlamVjdCBwb2xpY3kgd2FzIG92ZXJy aWRlbiBieSB0aGUgcmVjZWl2ZXIgYmVjYXVzZSBvZiBhbiBBUkMgZXZhbHVhdGlvbiwgd2hlbiB0 aGF0IGRhdGEgaXMgaW5jbHVkZWQgaW4gdGhlIHJlcG9ydCB0aGUgaW5kaXJlY3QgbWFpbCBmbG93 IGNhbiBiZSBjbGVhcmx5IHNlZW4sIHdoaWNoIHdvdWxkIG5vdCBiZSB0aGUgY2FzZSBpZiBBUkMg d2VyZSBpbmNsdWRlZCBhcyBhIHNlcGFyYXRlIHJlcG9ydC4NCg0KVGhpcyBjb3VsZCBiZSBpbmNs dWRlZCBpbiBhbiA8ZXh0ZW5zaW9uPiBlbGVtZW50LCBvciBjb3VsZCBiZSBpbmNsdWRlZCBkaXJl Y3RseSBpbiB0aGUgYXV0aF9yZXN1bHRzIHNlY3Rpb24gb2YgdGhlIHJlcG9ydCwgYmFzZWQgb24g YW4gYXNzdW1wdGlvbiB0aGF0IHRoZSB0aGluZ3MgYmVpbmcgcmVwb3J0ZWQgU0hPVUxEIGhhdmUg YW4gYXV0aGVudGljYXRpb24gcmVzdWx0cyBlbnRyeSBpbiBwcm9jZXNzZWQgbWFpbC4NCg0KPGF1 dGhfcmVzdWx0cz4NCjxka2ltPi4uLjwvZGtpbT4NCjxzcGY+Li4uPC9zcGY+DQo8YXJjPiAoYXMg ZGVmaW5lZCBpbiBhcmMgc3RhbmRhcmQpIDwvYXJjPg0KPGZvbz4gKGFzIGRlZmluZWQgaW4gZm9v IHN0YW5kYXJkKSA8L2Zvbz4NCjwvYXV0aF9yZXN1bHRzPg0KDQpUaGVzZSB3b3VsZCBiZSBkZWZp bmVkIGluIGEgcmVnaXN0cnkgd2l0aCByZWZlcmVuY2UgdG8gZWFjaCBzdGFuZGFyZCwgYW5kIHBh cnNlcnMgd291bGQgaWdub3JlIGFueSBzZWN0aW9ucyB0aGV5IGRpZCBub3QgdW5kZXJzdGFuZC4N Cg0KT24gRnJpLCA0IERlYyAyMDIwLCBhdCA2OjQzIEFNLCBBbGVzc2FuZHJvIFZlc2VseSB3cm90 ZToNCk9uIFRodSAwMy9EZWMvMjAyMCAxOTo1NDo1MSArMDEwMCBCcm90bWFuLCBBbGV4IHdyb3Rl Og0KPg0KPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+IEZyb206IGRtYXJjIDxkbWFy Yy1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpkbWFyYy1ib3VuY2VzQGlldGYub3JnPj4gT24gQmVo YWxmIE9mIEFsZXNzYW5kcm8gVmVzZWx5DQo+PiBTZW50OiBUaHVyc2RheSwgRGVjZW1iZXIgMywg MjAyMCA2OjI0IEFNDQo+PiBUbzogZG1hcmNAaWV0Zi5vcmc8bWFpbHRvOmRtYXJjQGlldGYub3Jn Pg0KPj4gU3ViamVjdDogUmU6IFtkbWFyYy1pZXRmXSBEaXNjdXNzaW9uIC0gQVJDL0V4dGVuc2li bGUgUmVwb3J0aW5nIChUaWNrZXQgIzU2KQ0KPj4NCj4+IE9uIFdlZCAwMi9EZWMvMjAyMCAyMDo0 Njo1NCArMDEwMCBCcm90bWFuLCBBbGV4IHdyb3RlOg0KPj4+DQo+Pj4gV2hpbGUgdGhpcyB0aWNr ZXQvZW5oYW5jZW1lbnQgc3BlY2lmaWNhbGx5IG1lbnRpb25zIEFSQywgSSBjb3VsZA0KPj4+IHBl cmhhcHMgc2VlIHRoZSB1c2VmdWxuZXNzIGluIG90aGVyIHBsYWNlcy4gIEl0IHNlZW1zIGxpa2Ug aXQgd291bGQgYmUNCj4+PiBtb3JlIGJlbmVmaWNpYWwgdG8gY3JlYXRlIGEgbWV0aG9kIGJ5IHdo aWNoIG90aGVyIGRvY3VtZW50cyBjb3VsZA0KPj4+IHByb3ZpZGUgWE1MLSBiYXNlZCAiZXh0ZW5z aW9ucyIgdG8gdGhlIHJlcG9ydC4gIFRoaXMgd291bGQgYWxsb3cNCj4+PiBtZWNoYW5pc21zIHJl bHlpbmcgb24gRE1BUkMgdG8gaW5kZXBlbmRlbnRseSBkZWZpbmUgdGhlaXIgcmVwb3J0aW5nDQo+ Pj4gc2NoZW1hIHRvIGJlIGluY2x1ZGVkIGluIERNQVJDIGFnZ3JlZ2F0ZSByZXBvcnRzLiAgQWx0 ZXJuYXRlbHksIHdlIGNvdWxkDQo+Pj4gZm9jdXMgc3BlY2lmaWNhbGx5IG9uIEFSQywgYW5kIHdv cmsgdG8gaW5jbHVkZSB0aGF0IGluIHRoZSBiYXNlIFhNTC4NCj4+PiBUaGlzIG1lYW5zIHRoYXQg YW55IGxhdGVyIHJlcG9ydGluZyByZXF1aXJlbWVudHMgY291bGQgYWdhaW4gcmVxdWlyZQ0KPj4+ IGNoYW5nZXMgdG8gdGhlIGNvcmUgZHJhZnRzLj4+Pg0KPj4NCj4+DQo+PiBBbm90aGVyIHBvc3Np YmlsaXR5IGlzIGZvciBBUkMgdG8gZGVmaW5lIGl0cyBvd24gcmVwb3J0IGZvcm1hdC4gIEhpamFj a2luZw0KPj4gcnVhPSB0YXJnZXRzIHRvIHNlbmQgYSBkaWZmZXJlbnQga2luZCBvZiByZXBvcnQg c2hvdWxkIGJlIGFsbG93ZWQuDQo+PiBPdGhlcndpc2UsIHdlIGNvdWxkIGRlZmluZSBhIG5ldyB0 YWcsIGUuZy4gcnVlPSAoZSBmb3IgRXh0ZW5zaW9uKS4+Pg0KPj4gSW4gZWl0aGVyIGNhc2UsIGFz IHdlJ3JlIGludHJvZHVjZSB2YXJpYXRpb25zIGluIGFnZ3JlZ2F0ZSByZXBvcnQgY29udGVudCwN Cj4+IHdlIGhhdmUgdG8gZGV2aXNlIGEgbWV0aG9kIGZvciBkZXRlcm1pbmluZyB3aGF0IHZlcnNp b24va2luZCBvZiByZXBvcnQgaXMNCj4+IGF0dGFjaGVkIHRvIGEgZ2l2ZW4gbWVzc2FnZS4+Pg0K Pg0KPiBXZSBjb3VsZCBhZGQgYW4gZWxlbWVudCBjYWxsZWQgIjxleHRlbnNpb25zPiIsIGFuZCB3 ZSBhbGxvdyBBUkMgb3Igd2hhdGV2ZXINCj4gaXQgbWF5IGJlIHRvIGV4aXN0IHVuZGVyIHRoYXQg ZWxlbWVudC4gIFRoZSBBZ2dyZWdhdGUgUmVwb3J0aW5nIGRvY3VtZW50DQo+IG5lZWRzIHRvIHNw ZWNpZnkgdGhhdCBhbnkgZXh0ZW5zaW9ucyBhcmUgZXhwZWN0ZWQgdG8gYmUgcHJvcGVyIFhNTCwg YW5kIGlmDQo+IHRoZXJlIGFyZSBubyBleHRlbnNpb25zLCBhbiBlbXB0eSBlbGVtZW50IGlzIHN1 ZmZpY2llbnQuICBXZSBjb3VsZCBjcmVhdGUgYQ0KPiBiaXQgbW9yZSBzdHJ1Y3R1cmUgYXMgYSBy ZXF1aXJlbWVudCBpZiB3ZSB3YW50ZWQ6Pg0KPiA8ZXh0ZW5zaW9ucz4NCj4gICAgPGV4dGVuc2lv biBuYW1lPSJhcmMiIHN0YW5kYXJkPSJBUkNfRE1BUkNfUkVQT1JUSU5HX0VYVEVOU0lPTl9ERUZJ TklUSU9OIj4NCj4gICAgICAuLi4gKGFzIGRlZmluZWQgaW4gcmVmZXJlbmNlZCBzdGFuZGFyZCkN Cj4gICAgPC9leHRlbnNpb24+DQo+IDwvZXh0ZW5zaW9ucz4NCj4NCj4gSWYgYSByZXBvcnQgcGFy c2VyIGRvZXNuJ3Qga25vdyB3aGF0IEFSQyBpcyAob3IgYW55IG9mIHRoZSBleHRlbnNpb25zKSwg aXQgY291bGQgc2tpcCB0aGUgcHJvY2Vzc2luZy4gIEkgZG8gdW5kZXJzdGFuZCB0aGlzIG1lYW5z IHRoYXQgPGV4dGVuc2lvbnM+IGVsZW1lbnQgbWF5IGJyZWFrIGV4aXN0aW5nIHBhcnNlcnMsIGV2 ZW4gd2hlbiBlbXB0eSwgdGhvdWdoLCBJIGV4cGVjdCBtYW55IG9mIHRoZSB0aGluZ3Mgd2UncmUg cHJvcG9zaW5nIG1heSBmcmFjdHVyZSB0aGUgZXhwZWN0ZWQgWE1MLg0KDQoNCldlIGNhbiBkbyBh IGJldHRlciBqb2IgYXQgcHJvZHVjaW5nIGFnZ3JlZ2F0ZSByZXBvcnRzIHdpdGggYW4gYXV0b21h dGljYWxseSB2ZXJpZmlhYmxlIGNvbnRlbnQuICBGb3IgZXhhbXBsZSwgcHJlcGVuZGluZyBzdHVm ZiBsaWtlIHRoaXM6DQoNCjw/eG1sIHZlcnNpb249IjEuMCIgZW5jb2Rpbmc9IlVURi04Ij8+DQo8 ZG1hcmM6ZmVlZGJhY2sgeG1sbnM6eHM9Imh0dHA6Ly93d3cudzMub3JnLzIwMDEvWE1MU2NoZW1h LWluc3RhbmNlPGh0dHBzOi8vdXJsZGVmZW5zZS5jb20vdjMvX19odHRwOi93d3cudzMub3JnLzIw MDEvWE1MU2NoZW1hLWluc3RhbmNlX187ISFDUWwzbWNIWDJBIVdfeERYVng3MDdnYzYxTTVUQWgx dDFDTDYxd3BqNTdCSG5kYnRGeFVMbnhMemdnclhuWmZYTERQNVQ2UENXNW1xbUNFJD4iDQp4bWxu czpkbWFyYz0iaHR0cDovL2RtYXJjLm9yZy9kbWFyYy14bWwvMC4xPGh0dHBzOi8vdXJsZGVmZW5z ZS5jb20vdjMvX19odHRwOi9kbWFyYy5vcmcvZG1hcmMteG1sLzAuMV9fOyEhQ1FsM21jSFgyQSFX X3hEWFZ4NzA3Z2M2MU01VEFoMXQxQ0w2MXdwajU3QkhuZGJ0RnhVTG54THpnZ3JYblpmWExEUDVU NlBDWF83SEN2XyQ+Ig0KeHM6c2NoZW1hTG9jYXRpb249Imh0dHA6Ly9kbWFyYy5vcmcvZG1hcmMt eG1sLzAuMTxodHRwczovL3VybGRlZmVuc2UuY29tL3YzL19faHR0cDovZG1hcmMub3JnL2RtYXJj LXhtbC8wLjFfXzshIUNRbDNtY0hYMkEhV194RFhWeDcwN2djNjFNNVRBaDF0MUNMNjF3cGo1N0JI bmRidEZ4VUxueEx6Z2dyWG5aZlhMRFA1VDZQQ1hfN0hDdl8kPiBydWEueHNkIj4NCjxyZXBvcnRf bWV0YWRhdGE+DQogICAgICAgIC4uLg0KDQooUGVyaGFwcyBzb21ldGhpbmcgYmV0dGVyIHRoYW4g Imh0dHA6Ly9kbWFyYy5vcmcvZG1hcmMteG1sLzAuMTxodHRwczovL3VybGRlZmVuc2UuY29tL3Yz L19faHR0cDovZG1hcmMub3JnL2RtYXJjLXhtbC8wLjFfXzshIUNRbDNtY0hYMkEhV194RFhWeDcw N2djNjFNNVRBaDF0MUNMNjF3cGo1N0JIbmRidEZ4VUxueEx6Z2dyWG5aZlhMRFA1VDZQQ1hfN0hD dl8kPiIgZm9yIHRoZSB2ZXJzaW9uKQ0KDQpCdXQgdGhlbiwgd291bGQgdGhlIDxleHRlbnNpb25z PiBpbXBseSBkbWFyYy14bWwgZ3JhbW1hciBzaG91bGQgYmUgdXBncmFkZWQgZXZlcnkgdGltZSBB UkMgKG9yIHdoYXRldmVyKSBpcyB1cGdyYWRlZD8NCg0KU2VwYXJhdGUgcmVwb3J0cyBzb3VuZHMg c2ltcGxlci4NCg0KDQpCZXN0DQpBbGUNCi0tDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCmRt YXJjIG1haWxpbmcgbGlzdA0KZG1hcmNAaWV0Zi5vcmc8bWFpbHRvOmRtYXJjQGlldGYub3JnPg0K aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kbWFyYzxodHRwczovL3VybGRl ZmVuc2UuY29tL3YzL19faHR0cHM6L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RtYXJj X187ISFDUWwzbWNIWDJBIVdfeERYVng3MDdnYzYxTTVUQWgxdDFDTDYxd3BqNTdCSG5kYnRGeFVM bnhMemdnclhuWmZYTERQNVQ2UENjcDhKQVpyJD4NCg0KDQotLQ0KW0ltYWdlIHJlbW92ZWQgYnkg c2VuZGVyLl0NCg0KICBNYXJjIEJyYWRzaGF3DQogIG1hcmNicmFkc2hhdy5uZXQ8aHR0cHM6Ly91 cmxkZWZlbnNlLmNvbS92My9fX2h0dHA6L21hcmNicmFkc2hhdy5uZXQvX187ISFDUWwzbWNIWDJB IVdfeERYVng3MDdnYzYxTTVUQWgxdDFDTDYxd3BqNTdCSG5kYnRGeFVMbnhMemdnclhuWmZYTERQ NVQ2UENjd25zVDhaJD4gfCBAbWFyY2JyYWRzaGF3PGh0dHBzOi8vdXJsZGVmZW5zZS5jb20vdjMv X19odHRwczovdHdpdHRlci5jb20vbWFyY2JyYWRzaGF3X187ISFDUWwzbWNIWDJBIVdfeERYVng3 MDdnYzYxTTVUQWgxdDFDTDYxd3BqNTdCSG5kYnRGeFVMbnhMemdnclhuWmZYTERQNVQ2UENac2c0 UDR2JD4NCg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQpkbWFyYyBtYWlsaW5nIGxpc3QNCmRtYXJjQGlldGYub3JnPG1haWx0bzpkbWFyY0BpZXRm Lm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZG1hcmMNCg== --_000_MN2PR11MB43518DB46CF9F6C5A6080C65F7D70MN2PR11MB4351namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYg MyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIg MTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6TWVubG87DQoJ cGFub3NlLTE6MCAwIDAgMCAwIDAgMCAwIDAgMDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0K cC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVy bGluZTt9DQpzcGFuLmdtYWlsLW0tNTIwOTk1MTIyMDI0NjA3NTg5MWZvbnQNCgl7bXNvLXN0eWxl LW5hbWU6Z21haWwtbV8tNTIwOTk1MTIyMDI0NjA3NTg5MWZvbnQ7fQ0Kc3Bhbi5FbWFpbFN0eWxl MjANCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtY29tcG9zZTsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJ e21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6 OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29y ZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUg bXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2 IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFw ZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4N CjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9 IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0 aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPldl4oCZdmUgYWxyZWFkeSBtZW50aW9uZWQgQVJDLiZuYnNwOyBDb3Vs ZCBpdCBhbHNvIGJlIGV4dGVuZGVkIHRvIGFsbG93IGZvciBEb21haW4gUmVwdXRhdGlvbiByZXBv cnRpbmcgYmFjayB0byB0aGUgc2VuZGVyPyZuYnNwOyBJbnN0ZWFkIG9mIGEgY2VudHJhbCBhY2Nl c3MgcG9pbnQsIHRoZSBkYXRhIGlzIHNlbnQgcGVyaW9kaWNhbGx5IHRvIHRoZSBkb21haW4gaG9s ZGVyLCBhbmQgdGhleSBjYW4gdGhlbiB1dGlsaXplIHRoZSBkYXRhDQogYXMgdGhleSBzZWUgZml0 LiZuYnNwOyBJIGNvdWxkIGFsc28gc2VlIGEgdXNlIGNhc2UgZm9yIEJJTUkgcmVwb3J0aW5nLiZu YnNwOyBJ4oCZbSBzdXJlIG90aGVycyBjb3VsZCB0aGluayBvZiBvdGhlciB1c2UgY2FzZXMuPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPklmIHdlIHByZWZlciBpdCB0byBleGlzdCBvdXRzaWRlIG9m IHRoZSBtYWluIGJvZHkgb2YgZGF0YSwgaXQgbWF5IHJlc3VsdCBpbiBkdXBsaWNhdGlvbiBvZiBk YXRhLCBidXQgYWxzbyBhbGxvd3MgZm9yIG1vcmUgZmxleGliaWxpdHkuIFRoaXMgYWxsb3dzIHRo ZSBvcmlnaW5hbCBETUFSQyBBZ2dyZWdhdGUgZGF0YSB0byByZW1haW4gY29uc2lzdGVudCBhcyB3 ZWxsLiZuYnNwOyBPbiB0aGUgb3RoZXIgaGFuZCwgYWxsb3dpbmcNCiBpdCB0byBleGlzdCB3aXRo aW4gdGhlIHJlY29yZCBlbGVtZW50cyB3b3VsZCBhbGxvdyBpdCB0byBiZSBtb3JlIGVhc2lseSBj b3JyZWxhdGVkIHdpdGggdGhlIGV4aXN0aW5nIGRhdGEuJm5ic3A7IEkgdGhpbmsgbXkgKHNsaWdo dCkgcHJlZmVyZW5jZSAoYXMgYSByZXBvcnQgaGFuZGxlcikgaXMgdG8gaGF2ZSBpdCBvdXRzaWRl IG9mIHRoZSBtYWluIGJvZHkgb2YgdGhlIHJlcG9ydCwgYnV0IEkgY291bGQgYmUgc3dheWVkLjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPi0tPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BbGV4IEJy b3RtYW48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNyLiBFbmdpbmVlciwg QW50aS1BYnVzZSAmYW1wOyBNZXNzYWdpbmcgUG9saWN5PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5Db21jYXN0PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1s ZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0K PGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3Bh ZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+RnJvbTo8 L2I+IEVtaWwgR3VzdGFmc3NvbiAmbHQ7ZW1ndT00MGdvb2dsZS5jb21AZG1hcmMuaWV0Zi5vcmcm Z3Q7DQo8YnI+DQo8Yj5TZW50OjwvYj4gV2VkbmVzZGF5LCBEZWNlbWJlciAyMywgMjAyMCAyOjQ5 IFBNPGJyPg0KPGI+VG86PC9iPiBCcm90bWFuLCBBbGV4ICZsdDtBbGV4X0Jyb3RtYW5AY29tY2Fz dC5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBNYXJjIEJyYWRzaGF3ICZsdDttYXJjQG1hcmNicmFk c2hhdy5uZXQmZ3Q7OyBETUFSQyBJRVRGICZsdDtkbWFyY0BpZXRmLm9yZyZndDs8YnI+DQo8Yj5T dWJqZWN0OjwvYj4gUmU6IFtkbWFyYy1pZXRmXSBEaXNjdXNzaW9uIC0gQVJDL0V4dGVuc2libGUg UmVwb3J0aW5nIChUaWNrZXQgIzU2KTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPldoaWxlIHRoZSBjb21tb24gZm9ybWF0IHdvdWxkIGJlIGdyZWF0IGFzIGEg Y29uc3VtZXIgb2YgcmVwb3J0cywgSSdtIHdvbmRlcmluZyBob3cgbWFueSBkaWZmZXJlbnQmbmJz cDtyZXBvcnRzIHRoZXJlIHdvdWxkIGJlLiBOZXcgYXV0aCBzdGFuZGFyZHMgZG9uJ3QgcG9wIHVw IHRoYXQgb2Z0ZW4sIHNvIHdoYXQgb3RoZXIgcmVwb3J0cyBhcmUgeW91IHRoaW5raW5nIGFib3V0 PyBJIGNhbiBzZWUgdHdvIG9idmlvdXMgY2FuZGlkYXRlczsNCiB0aGUgbWFpbHNlcnZlciZuYnNw O3NvZnR3YXJlIGFuZCB0aGUgc3BhbS9hYnVzZSBwcmV2ZW50aW9uIHNvZnR3YXJlLiBJdCB3b3Vs ZCBiZSBpbnRlcmVzdGluZyB0byBzdXBwb3J0IHNvbWV0aGluZyBsaWtlIHRoYXQgdG9vIGJ1dCBz aG91bGRuJ3QgdGhvc2UganVzdCBwdXQgdGhlIHJlc3VsdHMgaW5zaWRlIHRoZSBka2ltL3NwZi9h cmMgYXV0aF9yZXN1bHRzPzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPi9FPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPk9uIFR1ZSwgRGVjIDgsIDIwMjAgYXQgMTI6MjkgUE0gQnJvdG1hbiwgQWxleCAmbHQ7QWxl eF9Ccm90bWFuPTxhIGhyZWY9Im1haWx0bzo0MGNvbWNhc3QuY29tQGRtYXJjLmlldGYub3JnIj40 MGNvbWNhc3QuY29tQGRtYXJjLmlldGYub3JnPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xp ZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44 cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQi Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkkgZmVlbCAoYXMgYSByZWNl aXZlciBvZiByZXBvcnRzKSBhcyB0aG91Z2ggYW5vdGhlciByZWFzb24gdG8gaGF2ZSB0aGVzZSBh cyBhIHNpbmdsZSByZXBvcnQgaXMgc28gdGhhdCB0aGUgcmVjZWl2ZXIgb2YgdGhlIHJlcG9ydCBp cyBhYmxlIHRvIG1vcmUgZWFzaWx5IGNvcnJlbGF0ZSB0aGUgZGF0YS90aW1lcy4mbmJzcDsNCiBJ IHNob3VsZCBiZSBhYmxlIHRvIGJlbGlldmUgdGhhdCBhbGwgcmVwb3J0cyAod2l0aG91dCBhIHNw ZWNpZmllZCByaSkgd2lsbCBiZSAwMDAwLTIzNTksIHRob3VnaCB0aGluZ3MgaGFwcGVuLCBhbmQg c3lzdGVtcyBicmVhayBkb3duLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPi0t PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkFsZXggQnJvdG1hbjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5Tci4gRW5naW5lZXIsIEFudGktQWJ1 c2UgJmFtcDsgTWVzc2FnaW5nIFBvbGljeTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj5Db21jYXN0PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRp dj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBw dDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+ RnJvbTo8L2I+IGRtYXJjICZsdDs8YSBocmVmPSJtYWlsdG86ZG1hcmMtYm91bmNlc0BpZXRmLm9y ZyIgdGFyZ2V0PSJfYmxhbmsiPmRtYXJjLWJvdW5jZXNAaWV0Zi5vcmc8L2E+Jmd0Ow0KPGI+T24g QmVoYWxmIE9mIDwvYj5NYXJjIEJyYWRzaGF3PGJyPg0KPGI+U2VudDo8L2I+IE1vbmRheSwgRGVj ZW1iZXIgNywgMjAyMCA1OjE3IFBNPGJyPg0KPGI+VG86PC9iPiBETUFSQyBJRVRGICZsdDs8YSBo cmVmPSJtYWlsdG86ZG1hcmNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5kbWFyY0BpZXRmLm9y ZzwvYT4mZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbZG1hcmMtaWV0Zl0gRGlzY3Vzc2lv biAtIEFSQy9FeHRlbnNpYmxlIFJlcG9ydGluZyAoVGlja2V0ICM1Nik8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlRoZXJlIGlzIHZhbHVlIGlu IGluY2x1ZGluZyB0aGVzZSBpbiBvbmUgcmVwb3J0LCBlc3BlY2lhbGx5IHdoZXJlIHRoZSBleHRl bmRlZCBwcm9wZXJ0eSBiZWluZyByZXBvcnRlZCBvbiBpbmZsdWVuY2VzIGhvdyBETUFSQyBpcyBl dmFsdWF0ZWQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj5Vc2luZyBBUkMgYXMgdGhlIGV4YW1wbGUsIHdoZW4gYSBwPXJlamVjdCBwb2xp Y3kgd2FzIG92ZXJyaWRlbiBieSB0aGUgcmVjZWl2ZXIgYmVjYXVzZSBvZiBhbiBBUkMgZXZhbHVh dGlvbiwgd2hlbiB0aGF0IGRhdGEgaXMgaW5jbHVkZWQgaW4gdGhlIHJlcG9ydCB0aGUgaW5kaXJl Y3QgbWFpbCBmbG93IGNhbg0KIGJlIGNsZWFybHkgc2Vlbiwgd2hpY2ggd291bGQgbm90IGJlIHRo ZSBjYXNlIGlmIEFSQyB3ZXJlIGluY2x1ZGVkIGFzIGEgc2VwYXJhdGUgcmVwb3J0LjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+VGhpcyBj b3VsZCBiZSBpbmNsdWRlZCBpbiBhbiAmbHQ7ZXh0ZW5zaW9uJmd0OyBlbGVtZW50LCBvciBjb3Vs ZCBiZSBpbmNsdWRlZCBkaXJlY3RseSBpbiB0aGUgYXV0aF9yZXN1bHRzIHNlY3Rpb24gb2YgdGhl IHJlcG9ydCwgYmFzZWQgb24gYW4gYXNzdW1wdGlvbiB0aGF0IHRoZSB0aGluZ3MgYmVpbmcgcmVw b3J0ZWQNCiBTSE9VTEQgaGF2ZSBhbiBhdXRoZW50aWNhdGlvbiByZXN1bHRzIGVudHJ5IGluIHBy b2Nlc3NlZCBtYWlsLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gY2xhc3M9ImdtYWlsLW0tNTIwOTk1MTIyMDI0NjA3NTg5MWZv bnQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtNZW5sbyZxdW90OyxzZXJpZiI+Jmx0 O2F1dGhfcmVzdWx0cyZndDs8L3NwYW4+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBjbGFzcz0iZ21haWwtbS01MjA5OTUx MjIwMjQ2MDc1ODkxZm9udCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O01lbmxvJnF1 b3Q7LHNlcmlmIj4mbHQ7ZGtpbSZndDsuLi4mbHQ7L2RraW0mZ3Q7PC9zcGFuPjwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g Y2xhc3M9ImdtYWlsLW0tNTIwOTk1MTIyMDI0NjA3NTg5MWZvbnQiPjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtNZW5sbyZxdW90OyxzZXJpZiI+Jmx0O3NwZiZndDsuLi4mbHQ7L3NwZiZn dDs8L3NwYW4+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBjbGFzcz0iZ21haWwtbS01MjA5OTUxMjIwMjQ2MDc1ODkxZm9u dCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O01lbmxvJnF1b3Q7LHNlcmlmIj4mbHQ7 YXJjJmd0OyAoYXMgZGVmaW5lZCBpbiBhcmMgc3RhbmRhcmQpICZsdDsvYXJjJmd0Ozwvc3Bhbj48 L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIGNsYXNzPSJnbWFpbC1tLTUyMDk5NTEyMjAyNDYwNzU4OTFmb250Ij48c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7TWVubG8mcXVvdDssc2VyaWYiPiZsdDtmb28mZ3Q7IChh cyBkZWZpbmVkIGluIGZvbyBzdGFuZGFyZCkgJmx0Oy9mb28mZ3Q7PC9zcGFuPjwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g Y2xhc3M9ImdtYWlsLW0tNTIwOTk1MTIyMDI0NjA3NTg5MWZvbnQiPjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtNZW5sbyZxdW90OyxzZXJpZiI+Jmx0Oy9hdXRoX3Jlc3VsdHMmZ3Q7PC9z cGFuPjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPlRoZXNlIHdvdWxkIGJlIGRlZmluZWQgaW4gYSByZWdpc3RyeSB3aXRoIHJl ZmVyZW5jZSB0byBlYWNoIHN0YW5kYXJkLCBhbmQgcGFyc2VycyB3b3VsZCBpZ25vcmUgYW55IHNl Y3Rpb25zIHRoZXkgZGlkIG5vdCB1bmRlcnN0YW5kLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+T24gRnJpLCA0IERlYyAyMDIwLCBhdCA2 OjQzIEFNLCBBbGVzc2FuZHJvIFZlc2VseSB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCIg aWQ9ImdtYWlsLW1fLTUyMDk5NTEyMjAyNDYwNzU4OTFxdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj5PbiBUaHUgMDMvRGVjLzIwMjAgMTk6NTQ6NTEgJiM0MzswMTAwIEJyb3RtYW4s IEFsZXggd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPiZndDsmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+Jmd0OyZndDsgLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jmd0OyZn dDsgRnJvbTogZG1hcmMgJmx0OzxhIGhyZWY9Im1haWx0bzpkbWFyYy1ib3VuY2VzQGlldGYub3Jn IiB0YXJnZXQ9Il9ibGFuayI+ZG1hcmMtYm91bmNlc0BpZXRmLm9yZzwvYT4mZ3Q7IE9uIEJlaGFs ZiBPZiBBbGVzc2FuZHJvIFZlc2VseTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj4mZ3Q7Jmd0OyBTZW50OiBUaHVyc2RheSwgRGVjZW1iZXIgMywg MjAyMCA2OjI0IEFNPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPiZndDsmZ3Q7IFRvOiZuYnNwOzxhIGhyZWY9Im1haWx0bzpkbWFyY0BpZXRmLm9y ZyIgdGFyZ2V0PSJfYmxhbmsiPmRtYXJjQGlldGYub3JnPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mZ3Q7Jmd0OyBTdWJqZWN0OiBSZTog W2RtYXJjLWlldGZdIERpc2N1c3Npb24gLSBBUkMvRXh0ZW5zaWJsZSBSZXBvcnRpbmcgKFRpY2tl dCAjNTYpPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPiZndDsmZ3Q7Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPiZndDsmZ3Q7IE9uIFdlZCAwMi9EZWMvMjAyMCAyMDo0Njo1NCAmIzQz OzAxMDAgQnJvdG1hbiwgQWxleCB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jmd0OyZndDsmZ3Q7Jm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZndDsmZ3Q7Jmd0OyBXaGls ZSB0aGlzIHRpY2tldC9lbmhhbmNlbWVudCBzcGVjaWZpY2FsbHkgbWVudGlvbnMgQVJDLCBJIGNv dWxkPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PiZndDsmZ3Q7Jmd0OyBwZXJoYXBzIHNlZSB0aGUgdXNlZnVsbmVzcyBpbiBvdGhlciBwbGFjZXMu Jm5ic3A7IEl0IHNlZW1zIGxpa2UgaXQgd291bGQgYmU8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jmd0OyZndDsmZ3Q7IG1vcmUgYmVuZWZpY2lh bCB0byBjcmVhdGUgYSBtZXRob2QgYnkgd2hpY2ggb3RoZXIgZG9jdW1lbnRzIGNvdWxkPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZndDsmZ3Q7 Jmd0OyBwcm92aWRlIFhNTC0gYmFzZWQgJnF1b3Q7ZXh0ZW5zaW9ucyZxdW90OyB0byB0aGUgcmVw b3J0LiZuYnNwOyBUaGlzIHdvdWxkIGFsbG93PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZndDsmZ3Q7Jmd0OyBtZWNoYW5pc21zIHJlbHlpbmcg b24gRE1BUkMgdG8gaW5kZXBlbmRlbnRseSBkZWZpbmUgdGhlaXIgcmVwb3J0aW5nPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZndDsmZ3Q7Jmd0 OyBzY2hlbWEgdG8gYmUgaW5jbHVkZWQgaW4gRE1BUkMgYWdncmVnYXRlIHJlcG9ydHMuJm5ic3A7 IEFsdGVybmF0ZWx5LCB3ZSBjb3VsZDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj4mZ3Q7Jmd0OyZndDsgZm9jdXMgc3BlY2lmaWNhbGx5IG9uIEFS QywgYW5kIHdvcmsgdG8gaW5jbHVkZSB0aGF0IGluIHRoZSBiYXNlIFhNTC48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jmd0OyZndDsmZ3Q7IFRo aXMgbWVhbnMgdGhhdCBhbnkgbGF0ZXIgcmVwb3J0aW5nIHJlcXVpcmVtZW50cyBjb3VsZCBhZ2Fp biByZXF1aXJlPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPiZndDsmZ3Q7Jmd0OyBjaGFuZ2VzIHRvIHRoZSBjb3JlIGRyYWZ0cy4mZ3Q7Jmd0OyZn dDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ Jmd0OyZndDsmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+Jmd0OyZndDsmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jmd0OyZndDsgQW5vdGhlciBwb3NzaWJpbGl0eSBpcyBm b3IgQVJDIHRvIGRlZmluZSBpdHMgb3duIHJlcG9ydCBmb3JtYXQuJm5ic3A7IEhpamFja2luZzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mZ3Q7 Jmd0OyBydWE9IHRhcmdldHMgdG8gc2VuZCBhIGRpZmZlcmVudCBraW5kIG9mIHJlcG9ydCBzaG91 bGQgYmUgYWxsb3dlZC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+Jmd0OyZndDsgT3RoZXJ3aXNlLCB3ZSBjb3VsZCBkZWZpbmUgYSBuZXcgdGFn LCBlLmcuIHJ1ZT0gKGUgZm9yIEV4dGVuc2lvbikuJmd0OyZndDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jmd0OyZndDsgSW4gZWl0aGVyIGNh c2UsIGFzIHdlJ3JlIGludHJvZHVjZSB2YXJpYXRpb25zIGluIGFnZ3JlZ2F0ZSByZXBvcnQgY29u dGVudCw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+Jmd0OyZndDsgd2UgaGF2ZSB0byBkZXZpc2UgYSBtZXRob2QgZm9yIGRldGVybWluaW5nIHdo YXQgdmVyc2lvbi9raW5kIG9mIHJlcG9ydCBpcyZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mZ3Q7Jmd0OyBhdHRhY2hlZCB0byBhIGdp dmVuIG1lc3NhZ2UuJmd0OyZndDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+Jmd0OyZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mZ3Q7IFdlIGNvdWxkIGFkZCBhbiBlbGVtZW50IGNh bGxlZCAmcXVvdDsmbHQ7ZXh0ZW5zaW9ucyZndDsmcXVvdDssIGFuZCB3ZSBhbGxvdyBBUkMgb3Ig d2hhdGV2ZXI8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+Jmd0OyBpdCBtYXkgYmUgdG8gZXhpc3QgdW5kZXIgdGhhdCBlbGVtZW50LiZuYnNwOyBU aGUgQWdncmVnYXRlIFJlcG9ydGluZyBkb2N1bWVudDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mZ3Q7IG5lZWRzIHRvIHNwZWNpZnkgdGhhdCBh bnkgZXh0ZW5zaW9ucyBhcmUgZXhwZWN0ZWQgdG8gYmUgcHJvcGVyIFhNTCwgYW5kIGlmPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZndDsgdGhl cmUgYXJlIG5vIGV4dGVuc2lvbnMsIGFuIGVtcHR5IGVsZW1lbnQgaXMgc3VmZmljaWVudC4mbmJz cDsgV2UgY291bGQgY3JlYXRlIGE8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+Jmd0OyBiaXQgbW9yZSBzdHJ1Y3R1cmUgYXMgYSByZXF1aXJlbWVu dCBpZiB3ZSB3YW50ZWQ6Jmd0OyZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj4mZ3Q7ICZsdDtleHRlbnNpb25zJmd0OzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mZ3Q7Jm5ic3A7Jm5i c3A7Jm5ic3A7ICZsdDtleHRlbnNpb24gbmFtZT0mcXVvdDthcmMmcXVvdDsgc3RhbmRhcmQ9JnF1 b3Q7QVJDX0RNQVJDX1JFUE9SVElOR19FWFRFTlNJT05fREVGSU5JVElPTiZxdW90OyZndDs8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jmd0OyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAuLi4gKGFzIGRlZmluZWQgaW4gcmVmZXJlbmNl ZCBzdGFuZGFyZCk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyAmbHQ7L2V4dGVuc2lvbiZndDs8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jmd0OyAmbHQ7 L2V4dGVuc2lvbnMmZ3Q7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPiZndDsmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+Jmd0OyBJZiBhIHJlcG9ydCBwYXJzZXIgZG9lc24ndCBrbm93 IHdoYXQgQVJDIGlzIChvciBhbnkgb2YgdGhlIGV4dGVuc2lvbnMpLCBpdCBjb3VsZCBza2lwIHRo ZSBwcm9jZXNzaW5nLiZuYnNwOyBJIGRvIHVuZGVyc3RhbmQgdGhpcyBtZWFucyB0aGF0ICZsdDtl eHRlbnNpb25zJmd0OyBlbGVtZW50IG1heSBicmVhayBleGlzdGluZw0KIHBhcnNlcnMsIGV2ZW4g d2hlbiBlbXB0eSwgdGhvdWdoLCBJIGV4cGVjdCBtYW55IG9mIHRoZSB0aGluZ3Mgd2UncmUgcHJv cG9zaW5nIG1heSBmcmFjdHVyZSB0aGUgZXhwZWN0ZWQgWE1MLjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPldlIGNhbiBkbyBhIGJl dHRlciBqb2IgYXQgcHJvZHVjaW5nIGFnZ3JlZ2F0ZSByZXBvcnRzIHdpdGggYW4gYXV0b21hdGlj YWxseSB2ZXJpZmlhYmxlIGNvbnRlbnQuJm5ic3A7IEZvciBleGFtcGxlLCBwcmVwZW5kaW5nIHN0 dWZmIGxpa2UgdGhpczo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPiZsdDs/eG1sIHZlcnNpb249JnF1b3Q7MS4wJnF1b3Q7IGVuY29kaW5n PSZxdW90O1VURi04JnF1b3Q7PyZndDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+Jmx0O2RtYXJjOmZlZWRiYWNrIHhtbG5zOnhzPSZxdW90Ozxh IGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5jb20vdjMvX19odHRwOi93d3cudzMub3JnLzIwMDEv WE1MU2NoZW1hLWluc3RhbmNlX187ISFDUWwzbWNIWDJBIVdfeERYVng3MDdnYzYxTTVUQWgxdDFD TDYxd3BqNTdCSG5kYnRGeFVMbnhMemdnclhuWmZYTERQNVQ2UENXNW1xbUNFJCIgdGFyZ2V0PSJf YmxhbmsiPmh0dHA6Ly93d3cudzMub3JnLzIwMDEvWE1MU2NoZW1hLWluc3RhbmNlPC9hPiZxdW90 OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj54 bWxuczpkbWFyYz0mcXVvdDs8YSBocmVmPSJodHRwczovL3VybGRlZmVuc2UuY29tL3YzL19faHR0 cDovZG1hcmMub3JnL2RtYXJjLXhtbC8wLjFfXzshIUNRbDNtY0hYMkEhV194RFhWeDcwN2djNjFN NVRBaDF0MUNMNjF3cGo1N0JIbmRidEZ4VUxueEx6Z2dyWG5aZlhMRFA1VDZQQ1hfN0hDdl8kIiB0 YXJnZXQ9Il9ibGFuayI+aHR0cDovL2RtYXJjLm9yZy9kbWFyYy14bWwvMC4xPC9hPiZxdW90Ozxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj54czpz Y2hlbWFMb2NhdGlvbj0mcXVvdDs8YSBocmVmPSJodHRwczovL3VybGRlZmVuc2UuY29tL3YzL19f aHR0cDovZG1hcmMub3JnL2RtYXJjLXhtbC8wLjFfXzshIUNRbDNtY0hYMkEhV194RFhWeDcwN2dj NjFNNVRBaDF0MUNMNjF3cGo1N0JIbmRidEZ4VUxueEx6Z2dyWG5aZlhMRFA1VDZQQ1hfN0hDdl8k IiB0YXJnZXQ9Il9ibGFuayI+aHR0cDovL2RtYXJjLm9yZy9kbWFyYy14bWwvMC4xPC9hPg0KIHJ1 YS54c2QmcXVvdDsmZ3Q7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPiZsdDtyZXBvcnRfbWV0YWRhdGEmZ3Q7PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyAuLi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPihQZXJoYXBzIHNvbWV0aGluZyBiZXR0ZXIgdGhhbiAm cXVvdDs8YSBocmVmPSJodHRwczovL3VybGRlZmVuc2UuY29tL3YzL19faHR0cDovZG1hcmMub3Jn L2RtYXJjLXhtbC8wLjFfXzshIUNRbDNtY0hYMkEhV194RFhWeDcwN2djNjFNNVRBaDF0MUNMNjF3 cGo1N0JIbmRidEZ4VUxueEx6Z2dyWG5aZlhMRFA1VDZQQ1hfN0hDdl8kIiB0YXJnZXQ9Il9ibGFu ayI+aHR0cDovL2RtYXJjLm9yZy9kbWFyYy14bWwvMC4xPC9hPiZxdW90Ow0KIGZvciB0aGUgdmVy c2lvbik8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPkJ1dCB0aGVuLCB3b3VsZCB0aGUgJmx0O2V4dGVuc2lvbnMmZ3Q7IGltcGx5IGRtYXJj LXhtbCBncmFtbWFyIHNob3VsZCBiZSB1cGdyYWRlZCBldmVyeSB0aW1lIEFSQyAob3Igd2hhdGV2 ZXIpIGlzIHVwZ3JhZGVkPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+U2VwYXJhdGUgcmVwb3J0cyBzb3VuZHMgc2ltcGxlci48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5C ZXN0PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PkFsZTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij4tLSZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPmRtYXJjIG1haWxpbmcgbGlzdDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48YSBocmVmPSJtYWlsdG86ZG1hcmNAaWV0Zi5vcmciIHRh cmdldD0iX2JsYW5rIj5kbWFyY0BpZXRmLm9yZzwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNl LmNvbS92My9fX2h0dHBzOi93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kbWFyY19fOyEh Q1FsM21jSFgyQSFXX3hEWFZ4NzA3Z2M2MU01VEFoMXQxQ0w2MXdwajU3QkhuZGJ0RnhVTG54THpn Z3JYblpmWExEUDVUNlBDY3A4SkFaciQiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RtYXJjPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9ImdtYWlsLW1fLTUyMDk5NTEyMjAyNDYwNzU4 OTFzaWc2MzY5NTExMyI+DQo8ZGl2IGlkPSJnbWFpbC1tXy01MjA5OTUxMjIwMjQ2MDc1ODkxc2ln MjE1MDMzMTMiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+LS08bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjx0YWJsZSBjbGFzcz0iTXNvTm9ybWFsVGFibGUiIGJvcmRlcj0i MCIgY2VsbHNwYWNpbmc9IjMiIGNlbGxwYWRkaW5nPSIwIj4NCjx0Ym9keT4NCjx0cj4NCjx0ZCBz dHlsZT0icGFkZGluZzouNzVwdCAuNzVwdCAuNzVwdCAuNzVwdCI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIHN0eWxlPSJib3JkZXI6c29saWQgd2luZG93dGV4dCAxLjBwdDtwYWRkaW5n OjBpbiI+PGltZyBib3JkZXI9IjAiIHdpZHRoPSIxMDAiIGhlaWdodD0iMTAwIiBzdHlsZT0id2lk dGg6MS4wNDE2aW47aGVpZ2h0OjEuMDQxNmluIiBpZD0iZ21haWwtbV8tNTIwOTk1MTIyMDI0NjA3 NTg5MV94MDA1Zl94MDAwMF9pMTAyNSIgc3JjPSJjaWQ6fldSRDAwMDEuanBnIiBhbHQ9IkltYWdl IHJlbW92ZWQgYnkgc2VuZGVyLiI+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjx0ZCBz dHlsZT0icGFkZGluZzouNzVwdCAuNzVwdCAuNzVwdCAuNzVwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj4mbmJzcDsgTWFyYyBCcmFkc2hhdzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDsmbmJzcDs8YSBocmVmPSJodHRw czovL3VybGRlZmVuc2UuY29tL3YzL19faHR0cDovbWFyY2JyYWRzaGF3Lm5ldC9fXzshIUNRbDNt Y0hYMkEhV194RFhWeDcwN2djNjFNNVRBaDF0MUNMNjF3cGo1N0JIbmRidEZ4VUxueEx6Z2dyWG5a ZlhMRFA1VDZQQ2N3bnNUOFokIiB0YXJnZXQ9Il9ibGFuayI+bWFyY2JyYWRzaGF3Lm5ldDwvYT4N CiB8Jm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLmNvbS92My9fX2h0dHBzOi90d2l0 dGVyLmNvbS9tYXJjYnJhZHNoYXdfXzshIUNRbDNtY0hYMkEhV194RFhWeDcwN2djNjFNNVRBaDF0 MUNMNjF3cGo1N0JIbmRidEZ4VUxueEx6Z2dyWG5aZlhMRFA1VDZQQ1pzZzRQNHYkIiB0YXJnZXQ9 Il9ibGFuayI+QG1hcmNicmFkc2hhdzwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC90ZD4N CjwvdHI+DQo8L3Rib2R5Pg0KPC90YWJsZT4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+X19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpkbWFyYyBtYWlsaW5n IGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86ZG1hcmNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5r Ij5kbWFyY0BpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL2RtYXJjIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9kbWFyYzwvYT48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90 ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_MN2PR11MB43518DB46CF9F6C5A6080C65F7D70MN2PR11MB4351namp_-- --_004_MN2PR11MB43518DB46CF9F6C5A6080C65F7D70MN2PR11MB4351namp_ Content-Type: image/jpeg; name="~WRD0001.jpg" Content-Description: ~WRD0001.jpg Content-Disposition: inline; filename="~WRD0001.jpg"; size=823; creation-date="Thu, 24 Dec 2020 13:45:31 GMT"; modification-date="Thu, 24 Dec 2020 13:45:31 GMT" Content-ID: <~WRD0001.jpg> Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAgGBgcGBQgHBwcJCQgKDBQNDAsLDBkSEw8UHRofHh0a HBwgJC4nICIsIxwcKDcpLDAxNDQ0Hyc5PTgyPC4zNDL/2wBDAQkJCQwLDBgNDRgyIRwhMjIyMjIy MjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjL/wAARCABkAGQDASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD3+iii gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo ooAKKKKACiiigAooooAKKKKACiiigD//2Q== --_004_MN2PR11MB43518DB46CF9F6C5A6080C65F7D70MN2PR11MB4351namp_-- From nobody Wed Dec 30 13:58: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 20F863A0994 for ; Wed, 30 Dec 2020 13:58:14 -0800 (PST) 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 tFaLXmjFd8dp for ; Wed, 30 Dec 2020 13:58:12 -0800 (PST) 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 E8D083A0949 for ; Wed, 30 Dec 2020 13:58:11 -0800 (PST) Received: by mail-qk1-x734.google.com with SMTP id 186so15093626qkj.3 for ; Wed, 30 Dec 2020 13:58:11 -0800 (PST) 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=nVYW67o9/5GZ6x5RZrLPFuizG5+uXpQ36q4bwsg4ytk=; b=HN25rCno9mBcWrLACKM6IkybC+uBbfDBXKk709dA8xDSiDR8nRwj/s+lmPqULjonXW gz2iNUXz43WO3JR1fNAYYvGgf1izms3dIFNFydbKstSAW7tKO02cqn8rON+piEeYMOH1 yolMLZTFVFrQsYUDlMCXlFl2ckY5Vw/as66jxgl2e+QipsuA1lalFm8jw2hXslUuzJbj LJ0Bjwm9Brcrpub5cSq5OgcakaMTrgMu60vZHKzMwCGb1XVrKQp9+E69XlW+892ACKom 1bvDJ6DohYt09fMbF9BwWB4hdti23omYiVeul6mCfixLBp0AsLCysb+8GqIIraEfr2tf ZRPw== 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=nVYW67o9/5GZ6x5RZrLPFuizG5+uXpQ36q4bwsg4ytk=; b=KSz47R2Jwr9cUi7gWBU37t/CdA71LjdtJssn9h4vK6mtONrIsrIkWjPx6z71l7i9Bu UrQde7lADCow8P4YUqaSafXI+lZA6PO1AbPU1r3MRwUGvZFZDpGBueq5A6dqgMPXx8yA +Yn069BUrSYhenQJIEEM+wpd+Jl86AjSyNAYWwRWRDyht2adZ4GZbnfDf0hJ4/Hv6Zcz PoSiubuYetKsjLRVQucAd/16ztEMt5/rIosIhZk2BFXyn9klIN+oDY0kYUmETA0OnpMf 8y46xh6/TI4WS67q+Bf73XXzRABoUqwenR8pa7PudB157TRU4JS+WgOVNhi0A6nbHldk PVAg== X-Gm-Message-State: AOAM531I4iYQf7pO/Prv+dDbcOlyEGF+Axtl5gz2BwtAn7CeUMNqTWqz 96+ehiGFmEKMMTheyrRgPM0kU2eRnqjblBlVrKxhA5VxyTY= X-Google-Smtp-Source: ABdhPJxKbs8d5aqGusYR2L+IJVeRDVQ8x06sPBb7obo28t2fTemK/jx/VqI1BXiHRam5aOwG1AeOTSjNKL+zbDnR+u8= X-Received: by 2002:a37:a058:: with SMTP id j85mr56963865qke.387.1609365490246; Wed, 30 Dec 2020 13:58:10 -0800 (PST) MIME-Version: 1.0 From: Todd Herr Date: Wed, 30 Dec 2020 16:57:54 -0500 Message-ID: To: IETF DMARC WG Content-Type: multipart/alternative; boundary="0000000000005c3e7505b7b59a1f" Archived-At: Subject: [dmarc-ietf] Ticket #80 - DMARCbis Should Have Clear and Concise Definition of DMARC X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Dec 2020 21:58:14 -0000 --0000000000005c3e7505b7b59a1f Content-Type: text/plain; charset="UTF-8" In mid-November, I shared some proposed text for new Abstract and Introduction sections - https://mailarchive.ietf.org/arch/msg/dmarc/wNE-cvIWQ3PXrM-42SozSocnnxs/ Dave Crocker submitted some suggestions on-list, and I noodled a bit with the text myself, and submit the following for your collective consideration: Abstract This document describes the Domain-based Message Authentication, Reporting, and Conformance (DMARC) protocol. DMARC permits the owner of an author's domain name to enable validation of the domain's use, to indicate the implication of failed validation, and to request reports about use of the domain name. Mail receiving organizations can use this information when evaluating disposition choices for incoming mail. This document obsoletes RFC 7489. [...] 1. Introduction RFC EDITOR: PLEASE REMOVE THE FOLLOWING PARAGRAPH BEFORE PUBLISHING: The source for this draft is maintained in GitHub at: https://github.com/ietf-wg-dmarc/draft-ietf-dmarc-dmarcbis (https://github.com/ietf-wg-dmarc/draft-ietf-dmarc-dmarcbis) The Sender Policy Framework ([RFC7208]) and DomainKeys Identified Mail ([RFC6376]) protocols provide domain-level authentication which is not directly associated with the RFC5322.From domain, and DMARC builds on those protocols. Using DMARC, Domain Owners that originate email can publish a DNS TXT record with their email authentication policies, preferred handling for mail that fails authentication checks, and request reports about use of the domain name. As with SPF and DKIM, DMARC authentication checks result in verdicts of "pass" or "fail". A DMARC pass verdict requires not only that SPF or DKIM pass for the message in question, but also that the domain validated by the SPF or DKIM check is aligned with the domain in the RFC5322.From header. In the DMARC protocol, two domains are said to be "in alignment" if they have the same Organizational Domain (a.k.a., relaxed alignment) or they are identical (a.k.a., strict alignment). A DMARC pass result indicates only that the RFC5322.From domain has been authenticated in that message; there is no explicit or implied value assertion attributed to a message that receives such a verdict. A mail-receiving organization that performs a DMARC validation check on inbound mail can choose to use the result and the published assessment by the originating domain for message disposition to inform its mail handling decision for that message. For a mail- receiving organization supporting DMARC, a message that passes validation is part of a message stream that is reliably associated with the domain owner. Therefore reputation assessment of that stream by the mail-receiving organization does not need to be encumbered by accounting for unauthorized use of the domain. A message that fails this validation cannot reliably be associated with the aligned domain and its reputation. DMARC also describes a reporting framework in which mail-receiving domains can generate regular reports containing data about messages seen that claim to be from domains that publish DMARC policies, and send those reports to one or more addresses as requested by the Domain Owner's DMARC policy record. Experience with DMARC has revealed some issues of interoperability with email in general that require due consideration before deployment, particularly with configurations that can cause mail to be rejected. These are discussed in Section 9. Thank you for your time. -- *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. --0000000000005c3e7505b7b59a1f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
In mid-November, I shared some proposed text for new Abstr= act and Introduction sections -=C2=A0https://ma= ilarchive.ietf.org/arch/msg/dmarc/wNE-cvIWQ3PXrM-42SozSocnnxs/

=
Dave Crocker submitted some suggestions on-list, and I noodled a= bit with the text myself, and submit the following for your collective con= sideration:

Abstract


=C2=A0=C2=A0 This document describes the Domain-based Me= ssage Authentication,

=C2=A0=C2=A0 Reporting, and Conformance (DMARC) protocol= .


=C2=A0=C2=A0 DMARC permits the owner of an author's = domain name to enable

=C2=A0=C2=A0 validation of the domain's use, to indi= cate the implication of failed

=C2=A0=C2=A0 validation, and to request reports about us= e of the domain name.

=C2=A0=C2=A0 Mail receiving organizations can use this i= nformation when evaluating

=C2=A0=C2=A0 disposition choices for incoming mail.


=C2=A0=C2=A0 This document obsoletes RFC 7489.


= [...]


1.=C2=A0 Introduction


=C2=A0=C2=A0 RFC EDITOR: PLEASE = REMOVE THE FOLLOWING PARAGRAPH BEFORE PUBLISHING:

=C2=A0=C2=A0 The source for this dra= ft is maintained in GitHub at:

=C2=A0=C2=A0 https://github.com/ietf-wg-d= marc/draft-ietf-dmarc-dmarcbis

=C2=A0=C2=A0 (https://github.com/ietf= -wg-dmarc/draft-ietf-dmarc-dmarcbis)


=C2=A0=C2=A0 The Sender Policy Framework ([RFC72= 08]) and DomainKeys Identified

=C2=A0=C2=A0 Mail ([RFC6376]) protocols provide domain-= level authentication which

=C2=A0=C2=A0 is not directly associated with the RFC5322.Fr= om domain, and DMARC

=C2=A0=C2=A0 builds on those protocols.=C2=A0 Using = DMARC, Domain Owners that originate

=C2=A0=C2=A0 email can publish a DNS TXT record wi= th their email authentication

=C2=A0=C2=A0 policies, preferred handling for mail that = fails authentication

=C2=A0=C2=A0 checks, and request reports about use of the domain = name.


=C2=A0=C2=A0 As with SPF and DKIM, DMARC authentication checks result in verdicts

=C2=A0=C2=A0 of "pass" or "fail".=C2=A0 A DMARC pass v= erdict requires not only that SPF

=C2=A0=C2=A0 or DKIM pass for the message in questio= n, but also that the domain

=C2=A0=C2=A0 validated by the SPF or DKIM check is aligned= with the domain in the

= =C2=A0=C2=A0 RFC5322.From header.=C2=A0 In the DM= ARC protocol, two domains are said to

=C2=A0=C2=A0 be "in alignment" if they= have the same Organizational Domain

=C2=A0=C2=A0 (a.k.a., relaxed alignment) or they = are identical (a.k.a., strict

=C2=A0=C2=A0 alignment).


=C2=A0=C2=A0 A DMARC pass result indicates on= ly that the RFC5322.From domain has

=C2=A0=C2=A0 been authenticated in that message; t= here is no explicit or implied

=C2=A0=C2=A0 value assertion attributed to a message th= at receives such a verdict.

=C2=A0=C2=A0 A mail-receiving organization that performs a= DMARC validation check

= =C2=A0=C2=A0 on inbound mail can choose to use the result and = the published

=C2= =A0=C2=A0 assessment by the originating domain for message dispositi= on to

=C2=A0=C2=A0= inform its mail handling decision for that message.=C2=A0 For a mail-

= =C2=A0=C2=A0 receiving organization supporting DMARC, a message that= passes

= =C2=A0=C2= =A0 validation is part of a message stream that is reliably associat= ed

=C2=A0=C2=A0 with the domain owner.=C2=A0Therefore reputation assessme= nt of that

=C2=A0= =C2=A0 stream by the mail-receiving organization does not need to be=

=C2=A0=C2=A0 encumbered by accounting for unauthorized use of the domain.=C2=A0= A

=C2=A0= =C2=A0 message that fails this validation cannot reliably be associa= ted with

=C2=A0=C2= =A0 the aligned domain and its reputation.


=C2=A0=C2=A0 DMARC also describes a rep= orting framework in which mail-receiving

=C2=A0=C2=A0 domains can generate regular rep= orts containing data about messages

=C2=A0=C2=A0 seen that claim to be from domains th= at publish DMARC policies, and

=C2=A0=C2=A0 send those reports to one or more addresse= s as requested by the

=C2=A0=C2=A0 Domain Owner's DMARC policy record.

<= p style=3D"margin:0px;font:11px Menlo;color:rgb(0,0,0);min-height:13px">

=C2=A0=C2=A0 Experience w= ith DMARC has revealed some issues of interoperability

=C2=A0=C2=A0 with email in ge= neral that require due consideration before

=C2=A0=C2=A0 deployment, particularly with= configurations that can cause mail to

=C2=A0 =C2=A0be rejected.=C2=A0 These are discussed in Section 9.


Thank you for your time.

-= -

Todd Herr | Sr. Technical Program Manager
<= b>e: todd.herr@valimail.com<= /div>
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 recip= ient you are hereby notified of any use, disclosure, copying or distributio= n of the information included in this transmission is prohibited and may be= unlawful. Please immediately notify the sender by replying to this email a= nd then delete it from your system.

--0000000000005c3e7505b7b59a1f-- From nobody Wed Dec 30 14:19: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 01D9D3A09EF for ; Wed, 30 Dec 2020 14:19:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t9FFZYk_I6sw for ; Wed, 30 Dec 2020 14:18:58 -0800 (PST) Received: from mx0b-00143702.pphosted.com (mx0b-00143702.pphosted.com [148.163.141.77]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36F103A09E7 for ; Wed, 30 Dec 2020 14:18:58 -0800 (PST) Received: from pps.filterd (m0184889.ppops.net [127.0.0.1]) by mx0b-00143702.pphosted.com (8.16.0.43/8.16.0.43) with SMTP id 0BUMG7aX028517 for ; Wed, 30 Dec 2020 17:18:57 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.com; h=from : to : subject : date : message-id : content-type : content-transfer-encoding : mime-version; s=20190412; bh=GK9KH40l7EBX4wdh5Elicn5NmpBpnLKe6dCNHHUx6rg=; b=100PPlp1rPIho8W1FwVQZdzEaPs2g4NWnqVJTboiFaKoermPUdyBjZstih9Zh0zJ3knf d+8L1Snc6EvWyk4xAg+0XRT2AyUv1InWOGbiSFtHHX1QAKDP1kg4MB1nk1ByxgwYj0Gt rqCcV7RsOmGs/T/B2Bxz0bp0Udup/PkrLmqwM4htinpvXVsQNri1O8KL+7MOEjvnGZEL Ea2QUVjIlubWrG9MFe3Qiy5ps7dZKc0We0kn2YCu1qmmCDBGg7SNdoE7ul8gQaxYjBzK U8apCil9j8mGh7MTPf6oCKCmxqukjj1HlfHVW8y/7QmjFLPSUDC+EYT1f7EW05aGqqmY 9A== Received: from pacdcex49.cable.comcast.com (dlppfpt-wc-1p.slb.comcast.com [96.99.226.136]) by mx0b-00143702.pphosted.com with ESMTP id 35nywg7hm7-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for ; Wed, 30 Dec 2020 17:18:57 -0500 Received: from PACDCEX50.cable.comcast.com (24.40.2.149) by PACDCEX49.cable.comcast.com (24.40.2.148) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 30 Dec 2020 17:18:55 -0500 Received: from PACDCEXEDGE01.cable.comcast.com (76.96.78.71) by PACDCEX50.cable.comcast.com (24.40.2.149) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Wed, 30 Dec 2020 17:18:55 -0500 Received: from NAM10-MW2-obe.outbound.protection.outlook.com (104.47.55.108) by webmail.comcast.com (76.96.78.71) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 30 Dec 2020 17:18:36 -0500 Received: from MN2PR11MB4351.namprd11.prod.outlook.com (2603:10b6:208:193::31) by MN2PR11MB4632.namprd11.prod.outlook.com (2603:10b6:208:24f::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3700.28; Wed, 30 Dec 2020 22:18:35 +0000 Received: from MN2PR11MB4351.namprd11.prod.outlook.com ([fe80::7ca6:b482:a6b0:4d42]) by MN2PR11MB4351.namprd11.prod.outlook.com ([fe80::7ca6:b482:a6b0:4d42%7]) with mapi id 15.20.3700.031; Wed, 30 Dec 2020 22:18:35 +0000 From: "Brotman, Alex" To: DMARC IETF Thread-Topic: Clarification about data integrity within Aggregate Reports (Ticket #40) Thread-Index: Adbe970H9Y1q6TEdQzWwRVOyDn0z2A== Date: Wed, 30 Dec 2020 22:18:35 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=comcast.com; x-originating-ip: [2601:43:101:380:2423:843e:71e9:c926] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 75cb79da-0580-4d12-5264-08d8ad10d99b x-ms-traffictypediagnostic: MN2PR11MB4632: 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: 0AF4Q54RNVPaRF6XtHeo1aHi+eOwpdsDoYqYy05vpdKD6XY2AbdlaaUXv8okhmzrzCRKhol/Maqsj1oaMsqc31AV4SxpFeh5ul/comxMjqBTNd6V6jo4BxnvESqWI305TcaWHzeVgsPTuxNpeus9HiqjZHMMitCTRhDGZT7jCMFYv/vLjgTaCY1UPKroSqJJFYGF8uSb6xttPdy7mZr/hz++3nZP5rO31n74BPsJV6UMGiYtpa7NjC02d7QXvUSeOIYFV0dpFfJ7f6vkEP3SvwZ7nJ881dMwGJAgHhLc4oY63CGI9X+OsYFUwJNTUrmmr+HYu+PsAZ63ySO7OMRmJuJZlEdc8R/FJK3+mgFS1PtfBaeZdiTh+ikUoDLUEje+IwndmfVjKefJ6OZofZneN+gloM93dIm6CJnDPFvfy3NS9VP8GpJ8jE5IRWONae6sBKp212TzGMrjMfTo0FvaKw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR11MB4351.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(376002)(396003)(136003)(366004)(39860400002)(346002)(66946007)(478600001)(9686003)(66556008)(5660300002)(83380400001)(66446008)(33656002)(52536014)(8936002)(71200400001)(8676002)(6916009)(316002)(66476007)(86362001)(64756008)(186003)(4744005)(76116006)(55016002)(966005)(6506007)(2906002)(7696005); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: =?us-ascii?Q?M8Km+eByo4eycHKJrIQgR+JvkdZEYM4CQZJdhhnaJXLpj0mP/+C5buWY3/QQ?= =?us-ascii?Q?P02lM98AeK/ZNU10xex1YEsHrSI2r3Ro0kuViIzz1gmwcjVpb0z8F/A+d2hm?= =?us-ascii?Q?LVyUVEmN0JcKbxFQCZ8sGzlangGBh4P7OraThneOnKJOPRzaL60iUrbSRn3L?= =?us-ascii?Q?l76/2F3jrMIMTR9NtJ3WfX/r4oMPiv1bQZH9+8fNHrEXCFwmeknx6pWAxzHh?= =?us-ascii?Q?fzkoYKXtnhNGSRpUIltBzkfRG2QEp6ul8530ai9Q7m7Zpmzmy44s8OkYbOC+?= =?us-ascii?Q?ku1R8C/OAYSpUFQ+aP4z1mLDR2EVRDXa/9UenxmXSa/eJtuoBrjhqN7Rwcyv?= =?us-ascii?Q?tHyJcw4qtkQwXm9gWZETvk5DM81+GWSRQQyBHSN0iprCMRVVnLIZcP/RVoji?= =?us-ascii?Q?ZwKGiSeYB7pg5U++3jbhUCm1ExuDQWJ4/Er6bG5mUHiw1JO/SP4uEeO9KG1p?= =?us-ascii?Q?gruDQzc2xZNIBmLhQBS4Cdeefxiqbg9wqYHBNDktzam2gHGxE5jjJLQ8w4XN?= =?us-ascii?Q?fz3dIovSWZRy0RdYsOQ3vNEFGtaPJP/ymiwArXsP72NBSrR7k2LJQhRxjs7g?= =?us-ascii?Q?yKtSRG2Mbu4R8+U2658ziWV15PBN6/vM8PKWb3Y0b/ttDn8BaDx9diHWe70c?= =?us-ascii?Q?gdyzCiP1Q053jSFmAWEUB9LgSDuDCdCjb42I99pOMi4qqBo68iAmlIUpLGDb?= =?us-ascii?Q?ATEvuS6UioooXvVkFpJwJMWgV7DJlP2wZTKMhnSuta4vkOSVfqNlaNCAU3jp?= =?us-ascii?Q?u6PEKahU8pzDQQ0ig95TJwvpUa6HyIzgnYAPMtIZx1kwLNxNKg77JKbieZ4p?= =?us-ascii?Q?2ISDF+kB1burNiFmJOtiK8MbfDIg3UQVUKe+vDooc6QWMy98Cl9BgIUAixVV?= =?us-ascii?Q?IAoQFZBhVt3PVX1Ffqz8XID1wtE/X0PG+lRMeXvPf6nHYybtf2iT4sh7PIqL?= =?us-ascii?Q?NuA6V5HYTuToHcs9W9L0Bbd3EjB8qVlLa0oTB0ceZx0BVRzufqITxs2auvM7?= =?us-ascii?Q?FWmLJ58f6sNm/3WIz5aSipV5ToLJQng3BxjZntuIWXlnZW4=3D?= x-ms-exchange-transport-forked: True arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=FYcKhVfi/4d78duIM3wFRGO4Nvlf8zP0k+qQm9U6nnomKjnUVvMkr7DWBdyfFoGQyaNSLjwk/hrmPsWqhM4OiIKt+ujUiFHIZ1wahv+EAtE89hcpv5dKcS5VBHKN8dT6KZtSr0r/5eMAkgOORiu9Zu0bTT9vw+2/AZ6OBEDerFvJ12Y697qP1YEEUxUfYNJXy1DSNLJZ7DcatnTNy9wtDI5Ix/V4keaProuOAs+28nm+Cz18t195/fMBsBfJSsdE0Olx3LaHkz7jMbaOUhTs/2Mf3m8L41qs5FBGHKYZuopsSFcJfA/aGeTaZymkb6YkgwiX3kRZ+ekaN+7iqGxajg== 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=xTvJrBWLC8iYjt2ycj2Cq6w14QAjjGAzkPwPUzjlhSQ=; b=btcVlEQo+f4rBLUKnryOmozNA27nkNX7IfiiavqWUExpIYwM0UfmAewDSvsJPUFp7Mu10PNZI0Yby5mSbeo8QJnX3u2QNj+/2M1OTuVulj9G0/z2M9nhMuQZPM2LAMI6rSZaJbXNpfa5ILVY146yfCyjylchavwyoKsZDIyYqtVfVvZWSAuF5JSNTgncz9fVdjrhfrqAtIQwefEBcenz1mVIEsp0nnzQ4jhOcesig8703w5Awip0PKkDH51JOtwte45QE/E+CTriBsbv7V4fVY3y0ZM9m3SH6A2v6GkXnWANm98tHry+X/vRuJgdIfxOTAp2wriAeX9MQ12ZZJp3EQ== arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=comcast.com; dmarc=pass action=none header.from=comcast.com; dkim=pass header.d=comcast.com; arc=none x-ms-exchange-crosstenant-authas: Internal x-ms-exchange-crosstenant-authsource: MN2PR11MB4351.namprd11.prod.outlook.com x-ms-exchange-crosstenant-network-message-id: 75cb79da-0580-4d12-5264-08d8ad10d99b x-ms-exchange-crosstenant-originalarrivaltime: 30 Dec 2020 22:18:35.3782 (UTC) x-ms-exchange-crosstenant-fromentityheader: Hosted x-ms-exchange-crosstenant-id: 906aefe9-76a7-4f65-b82d-5ec20775d5aa x-ms-exchange-crosstenant-mailboxtype: HOSTED x-ms-exchange-crosstenant-userprincipalname: brVEaM9gI0mUsfQTL4RxZvFqzRdfZYAnL8EcUo08wC+8fHSXlatS2PjNEm343l+tjsYMNxbvyxMkClF/48b4kqMhhysvnmMnNI2ktv8avFM= x-ms-exchange-transport-crosstenantheadersstamped: MN2PR11MB4632 x-originatororg: comcast.com Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Forward AAETWQ X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.343, 18.0.737 definitions=2020-12-30_14:2020-12-30, 2020-12-30 signatures=0 X-Proofpoint-Spam-Reason: safe Archived-At: Subject: [dmarc-ietf] Clarification about data integrity within Aggregate Reports (Ticket #40) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 30 Dec 2020 22:19:00 -0000 Hello folks, There's an open ticket (https://trac.ietf.org/trac/dmarc/ticket/40) noting = that we should clarify what constitutes valid data in a report. For example= , the report cannot state that DMARC-DKIM was a "pass" when DKIM itself was= a failure. See the original thread here: https://mailarchive.ietf.org/arch/msg/dmarc/Ii_dLXFzBNnRP361F922ty789I8/ It seems like the gist is that within the report it should never happen tha= t DKIM or SPF are noted to have passed in the context of DMARC if they have= not passed on their own. It should also be properly noted by the reporter= if they override with local policy. Not by overriding the SPF/DKIM failur= es (and showing them as incorrectly passing), but instead by noting that lo= cal policy overrides properly (regardless of whether that override is highe= r or lower). Does that seem properly summarized? -- Alex Brotman Sr. Engineer, Anti-Abuse & Messaging Policy Comcast From nobody Wed Dec 30 15:22: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 3731D3A0B17 for ; Wed, 30 Dec 2020 15:22:55 -0800 (PST) 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 wKlTEHLo3zW0 for ; Wed, 30 Dec 2020 15:22:54 -0800 (PST) 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 0D9C13A0B16 for ; Wed, 30 Dec 2020 15:22:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bluepopcorn.net; s=supersize; h=Content-Type:MIME-Version:References: In-Reply-To:Message-ID:Date:Subject:Cc:To:From:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=9jKrSOQ/MPkdl8Dd4+VXeqiwvQPt56YiqA0FxmIpwdY=; b=eF0r24jC8jDmkpXiLd8W8dn82 JKNS5wguqlqVv3ELskdWb8A+1a9m0pWQEInvs4hTpUbYc4ptghcIH0tETopN+dO2DiCDfyco4FBUH 8uLG4PsDYm6DRn9Z2DdiCSBLHSCkA+zEbDhbU4tE5dONprEJ8NZ+nLUljfmYvTLyRosVo=; Received: from [2601:647:4400:1261:a85c:7e61:f695:5964] (helo=[10.10.20.144]) by v2.bluepopcorn.net with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kuknr-0001f0-8v; Wed, 30 Dec 2020 15:22:51 -0800 From: "Jim Fenton" To: "John Levine" Cc: dmarc@ietf.org, mike@mtcc.com Date: Wed, 30 Dec 2020 15:22:49 -0800 X-Mailer: MailMate (1.13.2r5673) Message-ID: <1429C59C-5DBC-4B35-B6D6-2A2D78C783F4@bluepopcorn.net> In-Reply-To: <20201229205922.BD91635185C5@ary.qy> References: <20201229205922.BD91635185C5@ary.qy> MIME-Version: 1.0 Content-Type: text/plain; format=flowed Archived-At: Subject: Re: [dmarc-ietf] Ticket #55 - Clarify legal and privacy implications of failure reports X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Dec 2020 23:22:55 -0000 On 29 Dec 2020, at 12:59, John Levine wrote: > In article <14d833ce-0ae0-f818-fd4f-95769266a8e0@mtcc.com> you write: >> >> On 12/29/20 12:10 PM, John Levine wrote: >>> A lot of tiny non-profits like Girl Scout troops use email addresses >>> at webmail providers and send their announcements through ESPs like >>> Constant Contact and Mailchimp. This is yet another situation where >>> DMARC can't describe an entirely normal mail setup. >>> >>> Constant Contact apparently got Yahoo to give them a signing key, >>> at least temporarily, but that doesn't scale. >> >> What gmail does for gsuite is generates (or not, who knows) a key and >> gives you the selector to add to your dns. I don't see why that >> doesn't >> scale for all situations. > > To point out the obvious, because they use a single address at > yahoo.com or gmail.com or hotmail.com, not a private domain. These are > tiny organizations that don't have a lot of computer expertise nor a > lot of need for it. But these Girl Scout troops are going to publish a DMARC policy despite their lack of expertise? From nobody Thu Dec 31 02:15: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 9AD143A0BCC for ; Thu, 31 Dec 2020 02:15:29 -0800 (PST) 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 auQI6WCEdeKC for ; Thu, 31 Dec 2020 02:15:27 -0800 (PST) Received: from mail.wordtothewise.com (mail.wordtothewise.com [104.225.223.158]) by ietfa.amsl.com (Postfix) with ESMTP id 26F8B3A0BBC for ; Thu, 31 Dec 2020 02:15:10 -0800 (PST) Received: from [192.168.0.227] (unknown [37.228.231.27]) by mail.wordtothewise.com (Postfix) with ESMTPSA id 88FD39F149 for ; Thu, 31 Dec 2020 02:15:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=wordtothewise.com; s=aardvark; t=1609409710; bh=D79shDmPv8dT6pNNqmSoZ6aS9yfE49A87urxn1Vun9U=; h=From:Subject:Date:References:To:In-Reply-To:From; b=ZYUtNSJkEWOhuKJ+xc5gYlAaEyZ4DBWmiRQ8k95ihXrKMsm+DmcuO8wjmG2FwEv7R KYVB/jo4WQoihqNx4uJgQQ4tQwcPuyvySLVVmndojdnxcH+d2uzhBNsv9OWeLBPN7Q 6Nj7I4rcti4qbSJsAhel6Ck/oCvjlG/sSMWD4dBk= From: Laura Atkins Content-Type: multipart/alternative; boundary="Apple-Mail=_D0C0126C-F915-41E9-9D87-B8A7BD518FBC" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Date: Thu, 31 Dec 2020 10:15:07 +0000 References: <20201229205922.BD91635185C5@ary.qy> <1429C59C-5DBC-4B35-B6D6-2A2D78C783F4@bluepopcorn.net> To: IETF DMARC WG In-Reply-To: <1429C59C-5DBC-4B35-B6D6-2A2D78C783F4@bluepopcorn.net> Message-Id: <290D16F6-9E1D-489C-856D-15E9DE010824@wordtothewise.com> X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [dmarc-ietf] Ticket #55 - Clarify legal and privacy implications of failure reports X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Dec 2020 10:15:30 -0000 --Apple-Mail=_D0C0126C-F915-41E9-9D87-B8A7BD518FBC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 30 Dec 2020, at 23:22, Jim Fenton wrote: >=20 > On 29 Dec 2020, at 12:59, John Levine wrote: >=20 >> In article <14d833ce-0ae0-f818-fd4f-95769266a8e0@mtcc.com> you write: >>>=20 >>> On 12/29/20 12:10 PM, John Levine wrote: >>>> A lot of tiny non-profits like Girl Scout troops use email = addresses >>>> at webmail providers and send their announcements through ESPs like >>>> Constant Contact and Mailchimp. This is yet another situation = where >>>> DMARC can't describe an entirely normal mail setup. >>>>=20 >>>> Constant Contact apparently got Yahoo to give them a signing key, >>>> at least temporarily, but that doesn't scale. >>>=20 >>> What gmail does for gsuite is generates (or not, who knows) a key = and >>> gives you the selector to add to your dns. I don't see why that = doesn't >>> scale for all situations. >>=20 >> To point out the obvious, because they use a single address at >> yahoo.com or gmail.com or hotmail.com, not a private domain. These = are >> tiny organizations that don't have a lot of computer expertise nor a >> lot of need for it. >=20 > But these Girl Scout troops are going to publish a DMARC policy = despite their lack of expertise? Many Girl Scout troops were affected when Yahoo published p=3Dreject. = Which is probably why John brought it up. This isn=E2=80=99t a = hypothetical, this is things that we know actually happened and real = world effects of DMARC.=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=_D0C0126C-F915-41E9-9D87-B8A7BD518FBC Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On 30 Dec 2020, at 23:22, Jim Fenton <fenton@bluepopcorn.net> wrote:

On = 29 Dec 2020, at 12:59, John Levine wrote:

In article <14d833ce-0ae0-f818-fd4f-95769266a8e0@mtcc.com> you = write:

On 12/29/20 12:10 PM, John Levine wrote:
A lot of tiny = non-profits like Girl Scout troops use email addresses
at = webmail providers and send their announcements through ESPs like
Constant Contact and Mailchimp.  This is yet another = situation where
DMARC can't describe an entirely normal = mail setup.

Constant Contact apparently got = Yahoo to give them a signing key,
at least temporarily, = but that doesn't scale.

What = gmail does for gsuite is generates (or not, who knows) a key and
gives you the selector to add to your dns. I don't see why = that doesn't
scale for all situations.

To point out the obvious, because = they use a single address at
yahoo.com or gmail.com or hotmail.com, not a private domain. These are
tiny organizations that don't have a lot of computer = expertise nor a
lot of need for it.

But these Girl Scout troops are = going to publish a DMARC policy despite their lack of expertise?

Many Girl = Scout troops were affected when Yahoo published p=3Dreject. Which is = probably why John brought it up. This isn=E2=80=99t a hypothetical, this = is things that we know actually happened and real world effects of = DMARC. 

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=_D0C0126C-F915-41E9-9D87-B8A7BD518FBC-- From nobody Thu Dec 31 04:13: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 048863A0AD6 for ; Thu, 31 Dec 2020 04:13:31 -0800 (PST) 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, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 kvjZvjUQPoFY for ; Thu, 31 Dec 2020 04:13:28 -0800 (PST) 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 BFF3F3A0AD4 for ; Thu, 31 Dec 2020 04:13:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1609416804; bh=VAtw5wlSmE6dvdvW9VsFUTYnt3KruRSf9KIHInZzI/4=; l=1004; h=To:References:From:Date:In-Reply-To; b=Dh2VGaErPcoz0GssfTvpDxh8Z1+phxEkiHfTVX7Ar4zVikQIYch4cjYNqdGO4LnVf BAWRed1ST+k4PSMbLp7kuh87vQ1Hl7vr6Oj/MOOL7mCZ33EiMHH3jdrOSZMNrZyXej N+gFPT7J4n2FffhpWb3loEqfxE1Zscb3ua/ACO9cD4Mj/Xr8R8ixPKnWAHJWE Authentication-Results: tana.it; auth=pass (details omitted) Original-From: Alessandro Vesely 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 00000000005DC07E.000000005FEDC064.0000024B; Thu, 31 Dec 2020 13:13:24 +0100 To: dmarc@ietf.org References: <20201204195833.6B48A28F892A@ary.qy> From: Alessandro Vesely Message-ID: <74b5c149-8b8c-8c98-d9ff-5121a544349c@tana.it> Date: Thu, 31 Dec 2020 13:13:24 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.6.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] Ticket #28 - Failure report mail loops X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Dec 2020 12:13:31 -0000 On Wed 30/Dec/2020 22:17:47 +0100 John R Levine wrote: > On Fri, 4 Dec 2020, John Levine wrote: >> In article <0408ae98-e1c1-71fe-fdd4-8bc7a7c151d3@tana.it> you write: >>> We would like to close this ticket by Dec 18, two weeks from now, so please get >>> on it. >>> >>> The ticket originated from John's comment, in May 2019: >>> >>>     Apropos recent discussions, we could recommend that failure reports be >>>     rate limited per recipient both to break loops and to deter indirect >>>     mail bombing. >> >> I have never gotten enough failure reports that handling them was even >> slightly inconvenient, and my addresses are on every spam list in the world. >> >> Has anyone else?  If don't have evidence that this is a real problem, I'd >> just close the ticket. > > The answer was apparently no, so I propose we close this with no change. Closed already on 18th, see: https://mailarchive.ietf.org/arch/msg/dmarc/FDVvP_DNMxCtUtSdoqHYtHxZRxw Best Ale -- From nobody Thu Dec 31 04:29: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 4E2B33A0B04 for ; Thu, 31 Dec 2020 04:29:42 -0800 (PST) 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, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 ygqJ9LQZsKvh for ; Thu, 31 Dec 2020 04:29:41 -0800 (PST) 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 C3C5D3A0B02 for ; Thu, 31 Dec 2020 04:29:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1609417778; bh=vVme1ENGOCUHmxKx+LM8hTy2ocqdgKGiEU/FbIeqT0k=; l=3988; h=To:References:From:Date:In-Reply-To; b=CovL0k3h9rA/oaDCI4fuLe9VM/oxKTimdHI/b5HaYJbtrRvos4ObyjbduKhM52DuR r0tGJoP98+Ssyx5SS9fgdIzUew1dFIHmJ3XTB6td1m/e+J/mPMJR4wXFTdsX2oDiDi lyBVncP3+jArsYibAAS/K65VanCOO5u/PITZus8JwENKDBH7SVPYgCaY7Bt0n Authentication-Results: tana.it; auth=pass (details omitted) Original-From: Alessandro Vesely 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.000000005FEDC432.000003BB; Thu, 31 Dec 2020 13:29:38 +0100 To: dmarc@ietf.org References: <609e1c9b-cc4d-d7d1-0fa8-79f515c1eee4@tana.it> <5b50a8ee-8f35-8ca1-b03d-eb4f8e697108@wisc.edu> From: Alessandro Vesely Message-ID: Date: Thu, 31 Dec 2020 13:29:36 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: <5b50a8ee-8f35-8ca1-b03d-eb4f8e697108@wisc.edu> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] Ticket #61 - Define and add a simplified (redacted) failure report X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 31 Dec 2020 12:29:42 -0000 On Thu 10/Dec/2020 00:48:12 +0100 Jesse Thompson wrote: > On 12/9/20 11:07 AM, Alessandro Vesely wrote: >> We would like to close this ticket by Dec 23, two weeks from now, so please get on it. >> >> The ticket text is: >> >>     It has been asked for a new report type (perhaps a subset of failure >>     reports) that provides minimal data from the email (specifically, the >>     initial ask is for the to: and from: email addresses only) in order to aid >>     identification of the email's destination (and hence, the owner who can >>     help with getting it authenticated) without providing other PII. >> >>     This is a significant use case for large organizations, where the >>     departments or other sub-organizations run their own emailing >>     infrastructure. This has been specifically requested by multiple >>     universities. >> >> >> DMARC failure reporting is based on Authentication Failure Reporting Using the Abuse Reporting Format (RFC 6591), which in turn is based on An Extensible Format for Email Feedback Reports (RFC 5965).  DMARC adds five fields for the second MIME part of the report.  The third part can be either the full message of just the rfc822-headers.  The latter is defined in The Multipart/Report Media Type for the Reporting of Mail System Administrative Messages (RFC 6522), which mentions that Received: fields can also be useful for diagnosing failures.  In any case, private data such as the local part of email addresses can be redacted according to Redaction of Potentially Sensitive Data from Mail Abuse Reports (RFC 6590). >> >> In order to be useful, reports should contain enough data to discern whether the failed message was abusive, and what stream does it belong to if it wasn't.  Should DMARC Failure Reporting (our document) include some guidance about what parts of the failed message to include and which ones to redact? > > During our DMARC deployment (and even today) I was frustrated that I could see from aggregate reports that an ESP (or some other type of hosting provider whereby the IP address alone wasn't identifiable enough) was using our domain, but I didn't know who within our organization was a customer of the ESP. Ultimately, I wanted to reach out to the customer and set them up with a subdomain to use with the ESP so they could send branded and DMARC SPF&DKIM-aligned email. Asking the ESP who they're allowing to use our domain was a dead-end because they considered that private customer information (irony!) and they're naturally inclined to make their customers happy by tolerating the use of the domain without complicating matters that may result in possibly losing the customer. > > Forensic reports are a useful mechanism to find examples of these messages and subsequently track down the customer on our end. Usually, seeing the local part of the address used in the From header (maybe coupled with the Subject) was enough information. I did struggle with the needle-haystack problem with these reports. It was challenging to find what I was looking for, and it was challenging to create a process for going through all of the reports in any meaningful way. Perhaps I didn't really find the right tool for the job, or perhaps the problem wasn't large enough for me to justify finding/developing the right tool. > > [...snipped Alternatives:...] I'm a bit lost about where we are at this point. The possibility to redact parts of the report is already mentioned in the draft. We could add the generic possibility to select which header fields to include in the report. For example, the draft might suggest to only include known header fields. That way one could drop all X-* fields with unknown binary content and any other scaring stuff. If one wants to only leave From: and To:, so be it. Their reports, their choice. Otherwise we can just close this ticket with WONTFIX. Opinions? Other ideas? Best Ale -- From nobody Thu Dec 31 06:10: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 D384F3A0C74 for ; Thu, 31 Dec 2020 06:10:53 -0800 (PST) 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, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 xWEEhnAVPqR4 for ; Thu, 31 Dec 2020 06:10:52 -0800 (PST) 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 8585A3A0C70 for ; Thu, 31 Dec 2020 06:10:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1609423848; bh=5/IChb7cxymezfLIyZY5d9gj7el6XNIKjgfAUyF41Jk=; l=1772; h=To:References:From:Date:In-Reply-To; b=C8aH/H2QT2pgXhOqkdmtzfOSg/oNeqBhIO43JTxw3AfqWjviGHzY2Fl6712cNwCAn WvHQofHHjFZy7yXX2UT0jZ+kPtc/ygMhbfV/pyaWMzr+SmsObAb6/awDyKTkSxu4ZY 2ypCBpW6cqdOoFkYzDg8AXBtMTidfOZ/7z8dAv/z4ff4IWTPWnzoLq2+xK8VC Authentication-Results: tana.it; auth=pass (details omitted) Original-From: Alessandro Vesely 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 00000000005DC026.000000005FEDDBE7.00000F0B; Thu, 31 Dec 2020 15:10:47 +0100 To: dmarc@ietf.org References: <20201229205922.BD91635185C5@ary.qy> <1429C59C-5DBC-4B35-B6D6-2A2D78C783F4@bluepopcorn.net> <290D16F6-9E1D-489C-856D-15E9DE010824@wordtothewise.com> From: Alessandro Vesely Message-ID: <7dc4203e-1140-8808-776c-e80e5b5f6565@tana.it> Date: Thu, 31 Dec 2020 15:10:47 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: <290D16F6-9E1D-489C-856D-15E9DE010824@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] Ticket #55 - Clarify legal and privacy implications of failure reports X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Dec 2020 14:10:54 -0000 On Thu 31/Dec/2020 11:15:07 +0100 Laura Atkins wrote: >> On 30 Dec 2020, at 23:22, Jim Fenton > On 29 Dec 2020, at 12:59, John Levine wrote: >>> In article <14d833ce-0ae0-f818-fd4f-95769266a8e0@mtcc.com you write: >>>> On 12/29/20 12:10 PM, John Levine wrote: >>>>> >>>>> A lot of tiny non-profits like Girl Scout troops use email addresses >>>>> at webmail providers and send their announcements through ESPs like >>>>> Constant Contact and Mailchimp.  This is yet another situation where >>>>> DMARC can't describe an entirely normal mail setup. >>>>> >>>>> Constant Contact apparently got Yahoo to give them a signing key, >>>>> at least temporarily, but that doesn't scale. >>>> >>>> What gmail does for gsuite is generates (or not, who knows) a key and >>>> gives you the selector to add to your dns. I don't see why that doesn't >>>> scale for all situations. >>> >>> To point out the obvious, because they use a single address at yahoo.com >>> or gmail.com or hotmail.com, not a private domain. These are tiny >>> organizations that don't have a lot of computer expertise nor a lot of >>> need for it. >> >> But these Girl Scout troops are going to publish a DMARC policy despite their >> lack of expertise? > > Many Girl Scout troops were affected when Yahoo published p=reject. Which is > probably why John brought it up. This isn’t a hypothetical, this is things that > we know actually happened and real world effects of DMARC. I'd guess the problem they experienced have been mailing list and submissions using ISP's bundled services or similar unauthorized MSAs. The former is fixed by From: rewriting, the latter has no possible fix. Are there other unwanted effects? Best Ale -- From nobody Thu Dec 31 06: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 00C833A0CCC for ; Thu, 31 Dec 2020 06:46:51 -0800 (PST) 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, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 jz_eedn5GlyV for ; Thu, 31 Dec 2020 06:46:49 -0800 (PST) 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 88D1C3A0CC7 for ; Thu, 31 Dec 2020 06:46:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1609426007; bh=cTNqwZat5ZBNBjxJA6duv4LBnRdW+cI0ba98+51OiPU=; l=1033; h=To:References:From:Date:In-Reply-To; b=C+e654sjx6ZpWFdn1mb/Cxcbw3+GJkxJfpqUjuhi7q3whtaUsUsNtnE/ctzhb9Dkk tO832uGhWO7SbTtZfjRRcptI3hWXNVoUU4S8dtAcFpzFnOKvfz4kURD1oxlyqHoJa/ hXIub3zZxAXxYMOkZdGpYHUkI2g10j5k3e1Bfy0aMLO/ZFqgV10/Hx4gliME7 Authentication-Results: tana.it; auth=pass (details omitted) Original-From: Alessandro Vesely 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 00000000005DC0CF.000000005FEDE456.00001290; Thu, 31 Dec 2020 15:46:46 +0100 To: dmarc@ietf.org References: <45b3df7-5c6-9744-2ca8-1542e1b33e7b@taugh.com> From: Alessandro Vesely Message-ID: <478c7b56-f2b4-c7c1-7722-27fdce4bb8e9@tana.it> Date: Thu, 31 Dec 2020 15:46:45 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: <45b3df7-5c6-9744-2ca8-1542e1b33e7b@taugh.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] Ticket #1 - SPF alignment X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 31 Dec 2020 14:46:51 -0000 On Wed 30/Dec/2020 22:06:01 +0100 John R Levine wrote: >> We would like to close this ticket by Dec 15, two weeks from now, so short >> trenchant comments are welcome. >> >> Ticket #1 is about SPF alignment.  We need to replace references to 4408 with >> 7408, ando clarify what if anything we do with SPF HELO checks if >> the MAIL FROM is null.  One possibility is to say only MAIL FROM SPF counts, >> if you want to align your bounces, sign them.  The other is to explicitly say >> that HELO alignment is OK on bounces. > > I didn't hear a lot of strong opinions, but I think they leaned in the > direction of only checking the MAIL FROM, since the name of the MTA often is > unrelated to the From: domain. > > This means that if you want your bounces to be DMARC aligned, they'd need DKIM > signatures. Bounces with HELO mta.example.com should have From: postmaster@mta.example.com, where example.com may be a virtual domain or the "real" domain name, depending on the configuration. Best Ale -- From nobody Thu Dec 31 07:02: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 757903A0CC5 for ; Thu, 31 Dec 2020 07:02:24 -0800 (PST) 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, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 wg9ty1weofld for ; Thu, 31 Dec 2020 07:02:08 -0800 (PST) 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 3F3D33A0CE5 for ; Thu, 31 Dec 2020 07:02:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1609426926; bh=soMkZTzxQGQyPPMgUPFA93OV2kwvRqAF/SNxBhgBIFU=; l=1329; h=To:References:From:Date:In-Reply-To; b=BQJRUgIKYys8a7wD91Ykc/khp2HX/Hy7NLOVAZSPfvRhCwrCyDFUtpbRhSW36Sest W93WNeDBqfgaBoLBAN/AzPljHnCbRQ6Ab1ZybL5qLlgbW9NTHO2MGFkpTt8mhOR736 H1Fo7EMorl9H0sue5TWK74W603+E92iJBZltrdMV67d+t6MdBmLKnsiuNJ1td Authentication-Results: tana.it; auth=pass (details omitted) Original-From: Alessandro Vesely 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 00000000005DC026.000000005FEDE7EE.0000144D; Thu, 31 Dec 2020 16:02:06 +0100 To: John R Levine , dmarc@ietf.org References: From: Alessandro Vesely Message-ID: <7d3be6c4-aa17-3c34-d8f0-4df51e46ccc1@tana.it> Date: Thu, 31 Dec 2020 16:02:06 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.6.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] Ticket #42 - Expand DMARC reporting URI functionality X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 31 Dec 2020 15:02:24 -0000 On Wed 30/Dec/2020 22:23:20 +0100 John R Levine wrote: > There was some discussion about the detail that if there are multiple addresses > in the rua= tag you send the report to all of them.  People were quite clear > that is a feature.  I proposed as a hack a ruap= tag for rua preferred, if the > reporting system can send reports to all of the URIs in the ruap tag it does > so, otherwise it uses rua as it does now.  That lets you put the https URIs in > the ruap tag which existing code will ignore. > > Didn't get a lot of comments pro or con on that one. I still like better sticking to a unique tag (rua=) and applying OR-slashes. With a comma, it is backward compatible: v=DMARC1; p=none; rua=mailto:local@example.com, mailto:report@service.example, /https://service.example/report/; (The first scheme without a leading slash introduces a new series of alternatives.) The main reason to stick to the same tag is to allow overriding. For example, if the above record were: $ORIGIN=_dmarc.example.com IN TXT "v=DMARC1; p=none; rua=mailto:local@example.com, mailto:report@service.example" Then service.example can override rua=: $ORIGIN=example.com._report._dmarc.service.example IN TXT "v=DMARC1; rua=mailto:report@service.example, /https://service.example/report/; Best Ale -- From nobody Thu Dec 31 07:27: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 51AA23A0D06 for ; Thu, 31 Dec 2020 07:27:25 -0800 (PST) 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, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 p_kIvBHR0Y20 for ; Thu, 31 Dec 2020 07:27:23 -0800 (PST) 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 897373A0D05 for ; Thu, 31 Dec 2020 07:27:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1609428441; bh=n1q1eml+HkoREYW7256o+FJppNn9ApBVUDrni4Ohosc=; l=1735; h=To:References:From:Date:In-Reply-To; b=DXCf+hyDoTMGOvpiKFAUhMlcgkjNbbLjJcDYWVqTK73xC+115LebKdiQtUHDm0ee8 SU9Q6kao/7/VJpFsdQL44KJoqZ/n9wBYJbjBQm6R0sHMUa27zXH5Z5/DnwoqCpAkSL NdKmiqbataawrGy0EKJqffFzBJjtSSbTUjoG6IuAXSst4oWOjWf0JIC1azxts Authentication-Results: tana.it; auth=pass (details omitted) Original-From: Alessandro Vesely 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 00000000005DC026.000000005FEDEDD9.00001711; Thu, 31 Dec 2020 16:27:21 +0100 To: dmarc@ietf.org References: From: Alessandro Vesely Message-ID: <59d0e09e-9296-c16e-94b1-8f344faf88d2@tana.it> Date: Thu, 31 Dec 2020 16:27:20 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.6.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] Clarification about data integrity within Aggregate Reports (Ticket #40) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 31 Dec 2020 15:27:25 -0000 On Wed 30/Dec/2020 23:18:35 +0100 Brotman, Alex wrote: > Hello folks, > > There's an open ticket (https://trac.ietf.org/trac/dmarc/ticket/40) noting that we should clarify what constitutes valid data in a report. For example, the report cannot state that DMARC-DKIM was a "pass" when DKIM itself was a failure. See the original thread here: > > https://mailarchive.ietf.org/arch/msg/dmarc/Ii_dLXFzBNnRP361F922ty789I8/ > > It seems like the gist is that within the report it should never happen that DKIM or SPF are noted to have passed in the context of DMARC if they have not passed on their own. It should also be properly noted by the reporter if they override with local policy. Not by overriding the SPF/DKIM failures (and showing them as incorrectly passing), but instead by noting that local policy overrides properly (regardless of whether that override is higher or lower). > > Does that seem properly summarized? If the aggregate report content, Section 2.2, was well explained, the above text would be redundant. The point is that Section 2.2 looks like a high level list of features. It is completely useless for implementing a report producer, let alone a consumer. We have to rewrite that section, possibly trying to re-use the same wording and the same order of appearance of concepts, so as to minimize readers' confusion, but strictly matching the content of Appendix A (was Appendix C). The consistency checks above can be useful for building verification tools. Let me take this occasion to recall that there are XML syntax check tools that can be used to automatically verify the syntax based on the schema. We should write a more compliant XML in order to use them. Best Ale -- From nobody Thu Dec 31 07:37: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 4FF1D3A0D2F for ; Thu, 31 Dec 2020 07:37:43 -0800 (PST) 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 (2048-bit key) header.d=iecc.com header.b=dU+9Uz3u; dkim=pass (2048-bit key) header.d=taugh.com header.b=n4bKpZg1 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YElf3l6CMMY9 for ; Thu, 31 Dec 2020 07:37:41 -0800 (PST) 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 EEF803A0D2C for ; Thu, 31 Dec 2020 07:37:40 -0800 (PST) Received: (qmail 5421 invoked from network); 31 Dec 2020 15:37:39 -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=152b.5fedf043.k2012; i=johnl-iecc.com@submit.iecc.com; bh=0i8PW8GYbtmbL9Q8Y7h23U0B1BgupGH+goQLpit+ymQ=; b=dU+9Uz3uJdAUoE38z/bSxomIOu7muvAgdLq+0WitZakbytnDLqPMLaArxkgaPPs22RTlP2DqR2Q1/rO4N3aW5dMz3oRZO0ax+s+1fWVNMNhYACwMEMyV3ijsFZUsOEvIewc1/ISazoBBEHGs2+72DPSSN+V+X05c3CLJ3GNAYgKT4QMWbCwaKpVbtpJHuERtcLtSZjeUjzkYbMjL7QJX4Sn2mT5wxFuolTftqEAF385Ahn45n7qHw6X4BI2fDkXEp1WhhE21LDdskHgTCwHkMI5fCx4J4H18qWn6oMxr2N3AFjRejGGIT5sp/hxN5v+LjsuDtAWNlHbYr3qe0ls4vg== 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=152b.5fedf043.k2012; olt=johnl-iecc.com@submit.iecc.com; bh=0i8PW8GYbtmbL9Q8Y7h23U0B1BgupGH+goQLpit+ymQ=; b=n4bKpZg14CfQnhXhVk8noWM7ZPUjttu1BpjqUDubgGUMqvCjhqld7RAQVBhJ+b58nCrVqrs4ro/CqvEIhDvtr60AizrXNSGhRJ2OhV4MacjWnuILP3k7W7eQLo+D31BhiyPMdf/pBeSe96frpM7F+Ck9U58ZIMc85PzWgqlx4s4UD+QVNRs9MsZUTI9/g1UCHG2dkNiuFJQOMWDRad5bs4l/zH0y0LCyU73lMKKmdLAkvam9sV4B72XUNUTWSL2JJoORZzuqQ5PO/KslK0dm9O1KggFGZUSdtVtLdq0uHE5KFSP2AnDzh4Z/1Kd4cyUMB58z3J9b3zlLP19qMcrAiA== 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 Dec 2020 15:37:38 -0000 Date: 31 Dec 2020 10:37:38 -0500 Message-ID: From: "John R Levine" To: "Alessandro Vesely" , dmarc@ietf.org In-Reply-To: <7d3be6c4-aa17-3c34-d8f0-4df51e46ccc1@tana.it> References: <7d3be6c4-aa17-3c34-d8f0-4df51e46ccc1@tana.it> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [dmarc-ietf] Ticket #42 - Expand DMARC reporting URI functionality X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 31 Dec 2020 15:37:43 -0000 On Thu, 31 Dec 2020, Alessandro Vesely wrote: > On Wed 30/Dec/2020 22:23:20 +0100 John R Levine wrote: >> [ add ruap= to allow https in preference to mailto ] > > I still like better sticking to a unique tag (rua=) and applying OR-slashes. > With a comma, it is backward compatible: > > v=DMARC1; p=none; rua=mailto:local@example.com, mailto:report@service.example, /https://service.example/report/; No, it's invalid according to the syntax in RFC 7489. We have no idea what existing implementations do with DMARC records with syntax errors. Here's an experiment -- put that slash syntax in the rua= in your DMARC record and see who does or doesn't continue sending reports. In the meantime, anyone else have an opinion either way about adding HTTPS reporting? Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From nobody Thu Dec 31 08:00: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 10BFF3A0D70 for ; Thu, 31 Dec 2020 08:00:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.85 X-Spam-Level: X-Spam-Status: No, score=-1.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iecc.com header.b=vVDPy/0i; dkim=pass (2048-bit key) header.d=taugh.com header.b=eEzLFj7w Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yws0AThsjK6y for ; Thu, 31 Dec 2020 08:00:32 -0800 (PST) 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 5228D3A0D6F for ; Thu, 31 Dec 2020 08:00:31 -0800 (PST) Received: (qmail 11249 invoked from network); 31 Dec 2020 16:00:31 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=2bee.5fedf59f.k2012; bh=3ZFC39tmg3tyh6mf+o1OJO9cJRwL2HQ+cYUAZix0mwk=; b=vVDPy/0iPZMR+/jt39Fhv1jTd+9Fjo82w4fegveEJMSzZsIizWNWH9MWDgIQZRDZ+x9D+lwBlz0VIvluC/n1GO3/HIl/8u3zZAR8V6mmquagkv81mEb4Nh6SPkaL473sVUen9rE0k0mz97IeVQNVAKvb11YscqOmkwFU37+g/QGCBKpUX2bMd61jc0n3ejWoAhkjuU6fuuYZtFzbznj8BXf27w4g40Sh2Q4QVx5aOaD8eoLIlOcRRmRbQAPJCZGSEjCe+X1/ke153QUik/smsVRvyqaIP0dmFqTeRrxyLUXvHDTa6Px/+Xh3fqT1jiA7I26QNIbqVKrBwr1GBGBpBg== DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=2bee.5fedf59f.k2012; bh=3ZFC39tmg3tyh6mf+o1OJO9cJRwL2HQ+cYUAZix0mwk=; b=eEzLFj7wBzTlikrAPK+U3CbAZTDN8QDXDK4iwcFYmaUMoXq7Pj48C2MCIDnTf7egvrrpwI8nvqW84idv4A590qfXmN38PmAPe7EdM+1TO2SMXIEM4klMDuj9c6PkDMq6YK8EJjVQHswImMHi2BUTlGCPTjZ7IBBd3szrLfdue3YaGYtOVeGpgWEIOEjpIXYQVcPmOj+tMgxJubcvkct8oEB8dk7KqC8WJZC5mmv9ADk7t0+0kDHxyTpz128rMTp4vAbU9boVxk87pS6a/JUnHwrfq+JAxCuPq7Gl5c0yiJQhhZPtM/eNbVTqxS3NtCjNxjGozgQGfYYPqukNcHSumQ== 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 Dec 2020 16:00:30 -0000 Received: by ary.qy (Postfix, from userid 501) id 20AFB3EE7AD7; Thu, 31 Dec 2020 11:00:29 -0500 (EST) Date: 31 Dec 2020 11:00:29 -0500 Message-Id: <20201231160030.20AFB3EE7AD7@ary.qy> From: "John Levine" To: dmarc@ietf.org Cc: vesely@tana.it In-Reply-To: <7dc4203e-1140-8808-776c-e80e5b5f6565@tana.it> Organization: Taughannock Networks X-Headerized: yes Cleverness: minimal Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] Ticket #55 - Clarify legal and privacy implications of failure reports X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Dec 2020 16:00:34 -0000 In article <7dc4203e-1140-8808-776c-e80e5b5f6565@tana.it> you write: >> Many Girl Scout troops were affected when Yahoo published p=reject. Which is >> probably why John brought it up. This isn’t a hypothetical, this is things that >> we know actually happened and real world effects of DMARC. > >I'd guess the problem they experienced have been mailing list and submissions >using ISP's bundled services or similar unauthorized MSAs. The former is fixed >by From: rewriting, the latter has no possible fix. Not a good guess. Please review previous messages in this thread for clues. >Are there other unwanted effects? The main effect is that the mail they'd been sending from their ESP with their Yahoo address on the From: line used to work, and now falls on the floor or worse. R's, John From nobody Thu Dec 31 08:02: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 400C13A0D70 for ; Thu, 31 Dec 2020 08:02:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.85 X-Spam-Level: X-Spam-Status: No, score=-1.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iecc.com header.b=MlTbW5py; dkim=pass (2048-bit key) header.d=taugh.com header.b=VPQcuJNv Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JK09CptsOr_J for ; Thu, 31 Dec 2020 08:02:00 -0800 (PST) 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 B7E9B3A0D6F for ; Thu, 31 Dec 2020 08:02:00 -0800 (PST) Received: (qmail 11711 invoked from network); 31 Dec 2020 16:01:59 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=2dbd.5fedf5f7.k2012; bh=9HvkWT86zdW148rPdxUooz08gs/xRvOs+K/8B6TGGhI=; b=MlTbW5pyYmqCv2z6roJQ+AbWdtt2+vrybBKCq2QiiOOvI8xqeKwJpoPtpusb3ptpA4Y+LmHWtLeA2muD7lcu9z8RhhHXjNuN31USwyTnCewY1pMeJZVsKiEfX+5KJ/D4itK6rD6/MfnTFXnjGDEJs0nyc84i7Ob6cjmLk/hxAih7v35Xq2AvdiJprQC0ejGJNPh213gP5Qsx2BSGIVHsmjWfn6cWazR+Qsdro3s+c54Qw3ydS6PWI90n6O8ZmkkRQ7dvpTVeDYAS35GDkJ7iMVJks0hiTQLqosdetUduQSRXcp95qF4na8u16y+tSryTeRwn1UdJNn9iRl2pjBhF6A== DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=2dbd.5fedf5f7.k2012; bh=9HvkWT86zdW148rPdxUooz08gs/xRvOs+K/8B6TGGhI=; b=VPQcuJNvuXtfX0IdIPv5BuR9yp+P4GE7PiQI2sgug2XvqQ0bdWEtNWV5lzz8JPZJuZPy9HPML5tnKBuw/WxMGOceA7sVliHiN6Pi4nfUmSbcFIfebijLZnzIMwoY2dZJwK0HAflaCVw3YRA3HpkOHqPY6O7OEANiOq0kMLnGmAvdDcH1O7kNb2RZB6Y46gSjNjJk9uxDmb5hj1JEUOrQCWYJYq4jQqUkwKmhdubPKUpAzfm9mTiXyftLOomVYWdjb0fZuPFMakLCQS56zcfrDgf7mdzGT9detPveb4t6LIl4RUXeO13xHvaIpB7p0CEtBghnD5nUD51kBT+IyzeCyw== 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 Dec 2020 16:01:59 -0000 Received: by ary.qy (Postfix, from userid 501) id 18CFC3EE7B0C; Thu, 31 Dec 2020 11:01:58 -0500 (EST) Date: 31 Dec 2020 11:01:58 -0500 Message-Id: <20201231160159.18CFC3EE7B0C@ary.qy> From: "John Levine" To: dmarc@ietf.org Cc: vesely@tana.it In-Reply-To: Organization: Taughannock Networks X-Headerized: yes Cleverness: minimal Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] Ticket #61 - Define and add a simplified (redacted) failure report X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 31 Dec 2020 16:02:02 -0000 In article you write: >On Thu 10/Dec/2020 00:48:12 +0100 Jesse Thompson wrote: >> On 12/9/20 11:07 AM, Alessandro Vesely wrote: >>> We would like to close this ticket by Dec 23, two weeks from now, so please get on it. >>> >>> The ticket text is: >>> >>>     It has been asked for a new report type (perhaps a subset of failure >>>     reports) that provides minimal data from the email ... >Otherwise we can just close this ticket with WONTFIX. Please do that. It was clear that we have nothing useful to say about what one might want to redact or be required to redact. R's, John From nobody Thu Dec 31 08:35: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 8A1063A0D9B for ; Thu, 31 Dec 2020 08:35:09 -0800 (PST) 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, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 WQ3BsKvEwdYc for ; Thu, 31 Dec 2020 08:35:08 -0800 (PST) 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 29FA13A0D9A for ; Thu, 31 Dec 2020 08:35:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1609432506; bh=wkRsdM4enaSZgWsM6OTYXYFBq3AFaMOjjhhVAGrkons=; l=1210; h=To:References:From:Date:In-Reply-To; b=Cro2qiPdIQc+dhTI/BjjIcpDUU0BNsujscTJzM9DnrD9HQdE15sV76fWWX/DQRtHa 0GJdjtrOZZD/rdt9hPK5MGGsAzjjjP10uuazF1hv/pTLw+0ae0/qWTCBABsTrlyof/ vqdEAt/utyJb0asJZWtU9s/ph0SQO0xk7RiQ3FeTPujVONapeaduKPzy/CF3j Authentication-Results: tana.it; auth=pass (details omitted) Original-From: Alessandro Vesely 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.000000005FEDFDBA.00001F82; Thu, 31 Dec 2020 17:35:06 +0100 To: John R Levine , dmarc@ietf.org References: <7d3be6c4-aa17-3c34-d8f0-4df51e46ccc1@tana.it> From: Alessandro Vesely Message-ID: <8b6605de-ca01-904c-de78-deae254e0891@tana.it> Date: Thu, 31 Dec 2020 17:35:05 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.6.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] Ticket #42 - Expand DMARC reporting URI functionality X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 31 Dec 2020 16:35:10 -0000 On Thu 31/Dec/2020 16:37:38 +0100 John R Levine wrote: > On Thu, 31 Dec 2020, Alessandro Vesely wrote: > >> On Wed 30/Dec/2020 22:23:20 +0100 John R Levine wrote: >>> [ add ruap= to allow https in preference to mailto ] >> >> I still like better sticking to a unique tag (rua=) and applying OR-slashes. >> With a comma, it is backward compatible: >> >> v=DMARC1; p=none; rua=mailto:local@example.com, mailto:report@service.example, /https://service.example/report/; > > No, it's invalid according to the syntax in RFC 7489. I see. We have: dmarc-auri = "rua" *WSP "=" *WSP dmarc-uri *(*WSP "," *WSP dmarc-uri) URI = scheme ":" hier-part [ "?" query ] [ "#" fragment ] scheme = ALPHA *( ALPHA / DIGIT / "+" / "-" / "." ) So /https cannot be a scheme. How about: v=DMARC1; p=none; rua=mailto:local@example.com, mailto:report@service.example, OR-https://service.example/report/; > We have no idea what existing implementations do with DMARC records with syntax errors. > > Here's an experiment -- put that slash syntax in the rua= in your DMARC record > and see who does or doesn't continue sending reports. Done, with the second alternative. Best Ale -- From nobody Thu Dec 31 09:26: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 7DAD23A0DF7 for ; Thu, 31 Dec 2020 09:26:29 -0800 (PST) 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, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 1lZKvAZUsJWv for ; Thu, 31 Dec 2020 09:26:28 -0800 (PST) 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 D49C93A0DF6 for ; Thu, 31 Dec 2020 09:26:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1609435586; bh=/yrQTswyhPdKfgn6TYLyB68V5p26cnD17pOgyLhMaIU=; l=928; h=From:To:References:Date:In-Reply-To; b=C4U0fZYg3xEP0qkF75noonFYKs4eAFAdyYJb7aJfTzsCip40434LUO0sIlsTIEayE HttKMTLW7ZZnWZrl9h+uXiZp98wHJn1YLuaL9M97w79Vs4zRtVJf1owrIT3SccmUGT 5sVLnEffiI+fC7YmRMdyLGkyIJH9b0/tHW3u1c9WV7NMgtMWUlbcPvGCh1wTj Authentication-Results: tana.it; auth=pass (details omitted) Original-From: Alessandro Vesely 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 00000000005DC0BB.000000005FEE09C1.000024EE; Thu, 31 Dec 2020 18:26:25 +0100 From: Alessandro Vesely To: Tim Wicinski , John R Levine , IETF DMARC WG , Dotzero References: <20201218023900.E73B82ACBB2B@ary.qy> <3034face-b6fc-0ce2-fa1b-f59210bd6f5b@tana.it> <46339b38-3b24-bcb7-5e73-8a97038ed69@taugh.com> <3997c81d-3b30-0823-a752-fb1d60a44593@tana.it> <74a5c37-19a6-6f6f-a51d-6e5cca5b29e8@taugh.com> <01RTICXKLL3E0085YQ@mauve.mrochek.com> Message-ID: Date: Thu, 31 Dec 2020 18:26:24 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.6.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] Ticket #55 - Clarify legal and privacy implications of failure reports X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Dec 2020 17:26:30 -0000 On Thu 24/Dec/2020 10:35:10 +0100 Alessandro Vesely wrote: > On Thu 24/Dec/2020 03:39:03 +0100 Tim Wicinski wrote: >> I Believe I agree with the current version, but can someone post what we >> think is the final text? > > > I posted it here: > https://github.com/ietf-wg-dmarc/draft-ietf-dmarc-failure-reporting > > I don't think the text is final, though.  Besides minor tweaks in the first > paragraphs of Section 3, the whole discussion about external destinations has > to be stroked and replaced with a reference to aggregate reporting. I removed duplicated text and adjusted references. Diffs available here: https://tools.ietf.org/rfcdiff?url1=draft-ietf-dmarc-failure-reporting-00&url2=https://raw.githubusercontent.com/ietf-wg-dmarc/draft-ietf-dmarc-failure-reporting/main/draft-ietf-dmarc-failure-reporting.txt If the WG agrees, I'd post that as -01 and close ticket #55. Best Ale -- From nobody Thu Dec 31 09:27: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 1E1D03A0DF8 for ; Thu, 31 Dec 2020 09:27:30 -0800 (PST) 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 (2048-bit key) header.d=iecc.com header.b=PBzplsnM; dkim=pass (2048-bit key) header.d=taugh.com header.b=hD5KcE5C Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id giuydD3eeO-Q for ; Thu, 31 Dec 2020 09:27:28 -0800 (PST) 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 B346E3A0DF6 for ; Thu, 31 Dec 2020 09:27:27 -0800 (PST) Received: (qmail 36568 invoked from network); 31 Dec 2020 17:27:26 -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=8ed6.5fee09fe.k2012; i=johnl-iecc.com@submit.iecc.com; bh=Q5RJYFq7yMGM+fdGf0GqK5wZYnnPSKfgQSfUeqGnDFA=; b=PBzplsnMoLXebEbkX9KJ4/iF42Oa8ch1iOywD7AWeCn5aaiaLhqdGtlN5UF6P+8b4PgVoAOBtKZ4Seaautm9sYGcDDDfjfETzDkh7xg/X3kKaGb0G0t7GW+AGWn9ryi327lTIriOJd3YkkbnkO8fx5cB7izAdddByqyUh3wNJEEIEMpGDbkB9w/VNK3ld2ThGdMVnLrnFUFy/V96dOZCAtwsHMfkYOSmB2R9L6ZbnImSgqCeoA5hB01VFbJJ7DxlKgD7Z2fU4XhDxcm9P64SqEGbmm5ZMn5eGwO/rzE8QgnEhIqMc52IjyocF7k1KUsH3VbNTdGJFpwO75dcrftrZA== 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=8ed6.5fee09fe.k2012; olt=johnl-iecc.com@submit.iecc.com; bh=Q5RJYFq7yMGM+fdGf0GqK5wZYnnPSKfgQSfUeqGnDFA=; b=hD5KcE5C3B4EtCzHhoEGMvlwZBUmxMBpPWZp3t6caxcmhiSkb1Qj4a+w15vYkHdhuqS+SuUe+/3zKoTZ9Q6CW2seApYKaXQXI1p1xKzq3Bq0/VpR0zzLRkGfx95oEKvH98RMLwoP2DFeKLKmTy3VxD2K1m/hQSISqlWoCegAPt2DEUsFm7wseN5Idygb2Oady+EJMRt5aQVgZoCD0JtAobhNgF4oMlKQc/eql0CbArVAcdpHppOSrUAajnTAymowk+PsOzfe9JJ0liwwjlyKMJgXS/Bgbrk2oEX18U6HzcfdLEVFVGoEA+FQSRN+pQuksuCshzJNA37uQxeIoxxHwg== 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 Dec 2020 17:27:26 -0000 Date: 31 Dec 2020 12:27:26 -0500 Message-ID: From: "John R Levine" To: "Alessandro Vesely" , "Tim Wicinski" , "IETF DMARC WG" In-Reply-To: References: <20201218023900.E73B82ACBB2B@ary.qy> <3034face-b6fc-0ce2-fa1b-f59210bd6f5b@tana.it> <46339b38-3b24-bcb7-5e73-8a97038ed69@taugh.com> <3997c81d-3b30-0823-a752-fb1d60a44593@tana.it> <74a5c37-19a6-6f6f-a51d-6e5cca5b29e8@taugh.com> <01RTICXKLL3E0085YQ@mauve.mrochek.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="0-2119058384-1609435646=:22099" Archived-At: Subject: Re: [dmarc-ietf] Ticket #55 - Clarify legal and privacy implications of failure reports X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Dec 2020 17:27:30 -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-2119058384-1609435646=:22099 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT Before we do that I think we should revisit whether we have one reporting draft or two. On Thu, 31 Dec 2020, Alessandro Vesely wrote: > On Thu 24/Dec/2020 10:35:10 +0100 Alessandro Vesely wrote: >> On Thu 24/Dec/2020 03:39:03 +0100 Tim Wicinski wrote: >>> I Believe I agree with the current version, but can someone post what we >>> think is the final text? >> >> >> I posted it here: >> https://github.com/ietf-wg-dmarc/draft-ietf-dmarc-failure-reporting >> >> I don't think the text is final, though.  Besides minor tweaks in the first >> paragraphs of Section 3, the whole discussion about external destinations >> has to be stroked and replaced with a reference to aggregate reporting. > > > I removed duplicated text and adjusted references. Diffs available here: > > https://tools.ietf.org/rfcdiff?url1=draft-ietf-dmarc-failure-reporting-00&url2=https://raw.githubusercontent.com/ietf-wg-dmarc/draft-ietf-dmarc-failure-reporting/main/draft-ietf-dmarc-failure-reporting.txt > > > If the WG agrees, I'd post that as -01 and close ticket #55. > > > Best > Ale > Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly --0-2119058384-1609435646=:22099-- From nobody Thu Dec 31 09:35: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 E9CC43A0DF9 for ; Thu, 31 Dec 2020 09:35:20 -0800 (PST) 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, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 TJg_fXSU29Jo for ; Thu, 31 Dec 2020 09:35:18 -0800 (PST) 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 20FD33A0DF8 for ; Thu, 31 Dec 2020 09:35:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1609436111; bh=3rjQ/T6vCLwixqrgUsR0B7AmEwm+/O5230Ggx93GRs8=; l=1184; h=To:References:From:Date:In-Reply-To; b=CcU02nqr/UN2zYXblZFffsPZGQQjbLlDvgweBL6+taCEPrUUvq7rAXCoSLy8WnzCe I/0JzkKm0A8NtGHCqOb7SiugkT35csogk+2+PTC7YJKyg9MuIEVi9qQReTyjY+Z9ir qslIA5dY9Y+L360S2vfAwplwzveE6XAK0ek9UQvqaIkZMPcS3awGGoB1ZjS4h Authentication-Results: tana.it; auth=pass (details omitted) Original-From: Alessandro Vesely 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.000000005FEE0BCF.000025DE; Thu, 31 Dec 2020 18:35:11 +0100 To: John Levine , dmarc@ietf.org References: <20201231160030.20AFB3EE7AD7@ary.qy> From: Alessandro Vesely Message-ID: <4bd444a4-0c34-467a-cfcb-a8f7c14b723d@tana.it> Date: Thu, 31 Dec 2020 18:35:10 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: <20201231160030.20AFB3EE7AD7@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] Ticket #55 - Clarify legal and privacy implications of failure reports X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Dec 2020 17:35:21 -0000 On Thu 31/Dec/2020 17:00:29 +0100 John Levine wrote: > In article <7dc4203e-1140-8808-776c-e80e5b5f6565@tana.it> you write: >>> Many Girl Scout troops were affected when Yahoo published p=reject. Which is >>> probably why John brought it up. This isn’t a hypothetical, this is things that >>> we know actually happened and real world effects of DMARC. >> >>I'd guess the problem they experienced have been mailing list and submissions >>using ISP's bundled services or similar unauthorized MSAs. The former is fixed >>by From: rewriting, the latter has no possible fix. > > Not a good guess. Please review previous messages in this thread for clues. Ah, yeah, the ESPs. Besides dmarc=fail, they also trigger some SA macros, such as FORGED_GMAIL_RCVD, FREEMAIL_FORGED_FROMDOMAIN, FREEMAIL_FROM, FROM_EXCESS_BASE64, HEADER_FROM_DIFFERENT_DOMAINS, HTML_IMAGE_RATIO_04, HTML_MESSAGE, ... >> Are there other unwanted effects? > > The main effect is that the mail they'd been sending from their ESP > with their Yahoo address on the From: line used to work, and now falls > on the floor or worse. Why can't the ESPs do From: rewriting? Best Ale -- From nobody Thu Dec 31 09:41: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 BF3533A0DF9 for ; Thu, 31 Dec 2020 09:41:22 -0800 (PST) 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, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 QoWSAoC2V-YH for ; Thu, 31 Dec 2020 09:41:21 -0800 (PST) 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 E0E8A3A0A2C for ; Thu, 31 Dec 2020 09:41:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1609436478; bh=x8WTqwbl1VCSUJ4wK+ddcnAaSBbbzoKz+GkrnWoNcBA=; l=1738; h=To:References:From:Date:In-Reply-To; b=ARGPIWDpdemfW0ePqjg6Ln06T92M6laIp2J/nM6WXHZLDVECkNG277x9z+L5BpC9M HXuE9ParJ16C6uxkxL4LN0QOW+bABjITkq8wDbhJlu/3I+bmY09GmbOPqduqS9N+x5 vY3RH56+KQSa5oMFEUp92F/RbbSNbEmUeyyOZDNHl/c37fUhR+IBJXPwdvVgA Authentication-Results: tana.it; auth=pass (details omitted) Original-From: Alessandro Vesely 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 00000000005DC0BB.000000005FEE0D3E.00002700; Thu, 31 Dec 2020 18:41:18 +0100 To: John R Levine , Tim Wicinski , IETF DMARC WG References: <20201218023900.E73B82ACBB2B@ary.qy> <3034face-b6fc-0ce2-fa1b-f59210bd6f5b@tana.it> <46339b38-3b24-bcb7-5e73-8a97038ed69@taugh.com> <3997c81d-3b30-0823-a752-fb1d60a44593@tana.it> <74a5c37-19a6-6f6f-a51d-6e5cca5b29e8@taugh.com> <01RTICXKLL3E0085YQ@mauve.mrochek.com> From: Alessandro Vesely Message-ID: <66d84313-6a4c-15f3-30bf-3210af74c920@tana.it> Date: Thu, 31 Dec 2020 18:41:17 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.6.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] Ticket #55 - Clarify legal and privacy implications of failure reports X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Dec 2020 17:41:23 -0000 On Thu 31/Dec/2020 18:27:26 +0100 John R Levine wrote: > Before we do that I think we should revisit whether we have one reporting draft > or two. That issue only touches ticket #55 because it's the only one which called for altering the I-D's text. Also having a -01 beside -00 is irrelevant to the question. Discussing the split deserves its own ticket, IMHO. Best Ale > On Thu, 31 Dec 2020, Alessandro Vesely wrote: > >> On Thu 24/Dec/2020 10:35:10 +0100 Alessandro Vesely wrote: >>> On Thu 24/Dec/2020 03:39:03 +0100 Tim Wicinski wrote: >>>> I Believe I agree with the current version, but can someone post what we >>>> think is the final text? >>> >>> >>> I posted it here: >>> https://github.com/ietf-wg-dmarc/draft-ietf-dmarc-failure-reporting >>> >>> I don't think the text is final, though.  Besides minor tweaks in the first >>> paragraphs of Section 3, the whole discussion about external destinations >>> has to be stroked and replaced with a reference to aggregate reporting. >> >> >> I removed duplicated text and adjusted references.  Diffs available here: >> >> https://tools.ietf.org/rfcdiff?url1=draft-ietf-dmarc-failure-reporting-00&url2=https://raw.githubusercontent.com/ietf-wg-dmarc/draft-ietf-dmarc-failure-reporting/main/draft-ietf-dmarc-failure-reporting.txt >> >> >> >> If the WG agrees, I'd post that as -01 and close ticket #55. >> >> >> Best >> Ale >> > > Regards, > John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY > Please consider the environment before reading this e-mail. https://jl.ly > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > From nobody Thu Dec 31 09:45: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 A79A43A0DF9 for ; Thu, 31 Dec 2020 09:45:01 -0800 (PST) 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, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 pNXkm6xwk8PT for ; Thu, 31 Dec 2020 09:45:00 -0800 (PST) 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 971E03A0A2C for ; Thu, 31 Dec 2020 09:45:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1609436698; bh=9AEh64K9GLhyrrF2KOGHtx/9uEHr2GsUGZQwxzU1H3k=; l=741; h=To:References:From:Date:In-Reply-To; b=BbCy8aq17wWzfUwP9P+qHD73ACrKqraeDc0i85dXtVB7zg3fbc+DQhZKICHuFlXLh OeeZLgqLL4+hBlAE/yan7CKSlA+ax4qnU9lHL3EEFD+QKUK76ZC4h1QQjnk1fNLAJp K9BYY0L6hN1MWo+9SSJBUVQNsRgmk1KNLRb8gmm25sDQvHI/Z/8r93zMmxtBL Authentication-Results: tana.it; auth=pass (details omitted) Original-From: Alessandro Vesely 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 00000000005DC0BB.000000005FEE0E1A.00002773; Thu, 31 Dec 2020 18:44:58 +0100 To: John Levine , dmarc@ietf.org References: <20201231160159.18CFC3EE7B0C@ary.qy> From: Alessandro Vesely Message-ID: <2c893f34-6ad8-167e-bea0-607e9686fb7f@tana.it> Date: Thu, 31 Dec 2020 18:44:57 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: <20201231160159.18CFC3EE7B0C@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] Ticket #61 - Define and add a simplified (redacted) failure report X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 31 Dec 2020 17:45:02 -0000 On Thu 31/Dec/2020 17:01:58 +0100 John Levine wrote: > In article you write: >>On Thu 10/Dec/2020 00:48:12 +0100 Jesse Thompson wrote: >>> On 12/9/20 11:07 AM, Alessandro Vesely wrote: >>>> We would like to close this ticket by Dec 23, two weeks from now, so please get on it. >>>> >>>> The ticket text is: >>>> >>>>     It has been asked for a new report type (perhaps a subset of failure >>>>     reports) that provides minimal data from the email ... > >> Otherwise we can just close this ticket with WONTFIX. > > Please do that. It was clear that we have nothing useful to say about > what one might want to redact or be required to redact. Done. Best Ale -- From nobody Thu Dec 31 09:51: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 C08B63A0DFF for ; Thu, 31 Dec 2020 09:51:13 -0800 (PST) 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 (2048-bit key) header.d=iecc.com header.b=Tpzdu1yF; dkim=pass (2048-bit key) header.d=taugh.com header.b=LHf2Scrx Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SZrsz3vYXy9Z for ; Thu, 31 Dec 2020 09:51:12 -0800 (PST) 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 565D13A0DFE for ; Thu, 31 Dec 2020 09:51:12 -0800 (PST) Received: (qmail 44653 invoked from network); 31 Dec 2020 17:51:11 -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=ae6b.5fee0f8f.k2012; i=johnl-iecc.com@submit.iecc.com; bh=XIBU/rN7GdSFUbFdhcS1SiFjucL6NnlwR7rlz58wgEE=; b=Tpzdu1yFqSW4gu5J6WLua9y8LVwLPgpgxwMVkDFfsgZQ1M49ui8pC/dyR2+lxqJPeJLY5Fk76H35HAtpzBb2FCW2rMa77Ty2xeh5QQNbWJ8X68tC3snYVFgL1sU6RCZjEHLu5i3TdGbO7jPlMAKvKbBHegZRx5hfUYjcR1xtg69wyfRhmr2cAC+VUh0TStMCzbdxdbEsBSd9FWuhv6cN+S6BEePBD37cpAu4L6iUqn8A60CZD01DCL40vR41CVZIhztRcB8sueOz8W4VMm+Jei3mPncqw6P0XeaGkyPA5BdF40M5gU+xJGU2Nx0TfdKWa6NV90kfjTWuOUPr5twr1g== 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=ae6b.5fee0f8f.k2012; olt=johnl-iecc.com@submit.iecc.com; bh=XIBU/rN7GdSFUbFdhcS1SiFjucL6NnlwR7rlz58wgEE=; b=LHf2ScrxsS/s+5kFUXRD9tNmV3ldcnV2uGtnkqcVHTt9dxmtA0MFqWnw6f/wN7zm0JJi9lD8czWnw+O5mFSi1rU0w5KzGn1PCrbbyfGREp7cChv0uXitK+w7GHJ1ACeTqC3HFCQ+a5tx72F35r+tjTC/29Hi59p9OZlJgvzduy11DjnXGMSyHg4Ywdmk46Y3AlNGF2awnD+g7YZANMHFo2oyRD9UhwmOW8gyaLHomPjuIRiCaN/K2rbDyGUHajGHJWR2tZvj9Ji/tqcAYF1aJYt48L+i+PGZ7c3ffh8RdCeDA2DRZCBmoXsU6VbZ3ERZbzJZFc8rF6P5aULcFBnkhg== 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 Dec 2020 17:51:10 -0000 Date: 31 Dec 2020 12:51:10 -0500 Message-ID: From: "John R Levine" To: "Alessandro Vesely" , dmarc@ietf.org In-Reply-To: <4bd444a4-0c34-467a-cfcb-a8f7c14b723d@tana.it> References: <20201231160030.20AFB3EE7AD7@ary.qy> <4bd444a4-0c34-467a-cfcb-a8f7c14b723d@tana.it> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [dmarc-ietf] Ticket #55 - Clarify legal and privacy implications of failure reports X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Dec 2020 17:51:14 -0000 >> The main effect is that the mail they'd been sending from their ESP >> with their Yahoo address on the From: line used to work, and now falls >> on the floor or worse. > > Why can't the ESPs do From: rewriting? To what? The Yahoo address is the only address the scout troop has? Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From nobody Thu Dec 31 10:06: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 2F0A23A0E13 for ; Thu, 31 Dec 2020 10:06:40 -0800 (PST) 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, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 9XXcKBWT1sqY for ; Thu, 31 Dec 2020 10:06:39 -0800 (PST) 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 E4B963A0E12 for ; Thu, 31 Dec 2020 10:06:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1609437995; bh=h68bBa5FAg6tT3PBtsm10Z2kFYmFSQJMdE/L9be1r4Q=; l=485; h=To:References:From:Date:In-Reply-To; b=AjpKH9+0RxgiZm86Z1Mpfb9lMDjCYNUmQxtpmbgpKcZSANkHTiNd3MjPtPh0N8CBj bTFDoZ1xftDY5TmH0H6/YpP1cuaej1CnLOqMpTDhaj+Uwsyg7MfIbhwsjexBQgsg40 sqAC0XdJAxFUEGU+K4fj93eST2RHNr97yUmCxBq5Q5WzIO/C+4Byg+KCpddNx Authentication-Results: tana.it; auth=pass (details omitted) Original-From: Alessandro Vesely 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.000000005FEE132B.0000298E; Thu, 31 Dec 2020 19:06:35 +0100 To: John R Levine , dmarc@ietf.org References: <20201231160030.20AFB3EE7AD7@ary.qy> <4bd444a4-0c34-467a-cfcb-a8f7c14b723d@tana.it> From: Alessandro Vesely Message-ID: <3999b617-b0e7-7341-93df-4a2ccea134e4@tana.it> Date: Thu, 31 Dec 2020 19:06:35 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.6.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] Ticket #55 - Clarify legal and privacy implications of failure reports X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Dec 2020 18:06:40 -0000 On Thu 31/Dec/2020 18:51:10 +0100 John R Levine wrote: >>> The main effect is that the mail they'd been sending from their ESP >>> with their Yahoo address on the From: line used to work, and now falls >>> on the floor or worse. >> >> Why can't the ESPs do From: rewriting? > > To what?  The Yahoo address is the only address the scout troop has? Copy that to Reply-To: and write a mangled From: that looks troopy but passes DMARC. Just like MLMs do. Best Ale -- From nobody Thu Dec 31 10:22: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 C32013A0E28 for ; Thu, 31 Dec 2020 10:22:55 -0800 (PST) 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 (2048-bit key) header.d=iecc.com header.b=ibN2sk5N; dkim=pass (2048-bit key) header.d=taugh.com header.b=ZA1KxF4e Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IaLQl7gmsoHd for ; Thu, 31 Dec 2020 10:22:54 -0800 (PST) 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 3C1E33A0E26 for ; Thu, 31 Dec 2020 10:22:53 -0800 (PST) Received: (qmail 68966 invoked from network); 31 Dec 2020 18:22:51 -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=10d5e.5fee16fb.k2012; i=johnl-iecc.com@submit.iecc.com; bh=pW6xWubZQYU6LeBrIsY5uzjl7D/fcUKNsxvkq1VoPwY=; b=ibN2sk5NWRR5DPU9c/l0FhXalrS1jdKJA7yQQYKBhB5GKY6nYSyNGMOjMUK/N01udVzvXmheENkUXCJJTwcqIepI2EgX/t4Npae5sCatF+dlBfIsEUZRB1/Atei1xCvR9IDwQEH/B270rYVR1aVhVc9K3HN7i693SFXfX7SaAotzJINdnhp6JnNEda85MqatndXmoWUbVZUJoCTi6RtFuVXYH6Am2qJUs6qc7XSvkgb2N0v+AL0eyYKS64NXVzoHYhvhdYgDd4ZoVff3+O2NPuWMACY5TtZpHCyyTpI5cI+1DZxkwaCKSpZ6Ib8hbxgmlcq2Gk3URj/RKPnbcE+rHg== 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=10d5e.5fee16fb.k2012; olt=johnl-iecc.com@submit.iecc.com; bh=pW6xWubZQYU6LeBrIsY5uzjl7D/fcUKNsxvkq1VoPwY=; b=ZA1KxF4edDDmqn5pZpJIag0ug4pYI+RvEDOZJWBpx34Y+fnWIVutFjZ/MLU71ZG2JM+4b3oe6kWxPYtviakP0Im03GGgysTtp+BEWVgPHmVsXLke69v8LkLTFR01/31AJ5ZzA+Qxj5HyPCITY5oi3kQ0Bkx5C5dwVxneEBbwprBUNPNttM+emS6518rO40uGc0+fS2LmXnGSKKCbSd2u0rDagGb93Vd0Pys7Ae8G2poRR3+SlXvLoXg258df7pwHyxvHJRvL8vzbWiV0lc2bVt4zlmt+Ujsg4iljHowgS6bQxnprSrL5voL/8eYqK0G/hzwbgln/1wquznZM3k+hgg== 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 Dec 2020 18:22:51 -0000 Date: 31 Dec 2020 13:22:50 -0500 Message-ID: <64cb14ed-322b-eecb-bed2-13349e19b833@taugh.com> From: "John R Levine" To: "Alessandro Vesely" , dmarc@ietf.org In-Reply-To: <3999b617-b0e7-7341-93df-4a2ccea134e4@tana.it> References: <20201231160030.20AFB3EE7AD7@ary.qy> <4bd444a4-0c34-467a-cfcb-a8f7c14b723d@tana.it> <3999b617-b0e7-7341-93df-4a2ccea134e4@tana.it> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="0-907014498-1609438971=:22541" Archived-At: Subject: Re: [dmarc-ietf] Ticket #55 - Clarify legal and privacy implications of failure reports X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Dec 2020 18:22:56 -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-907014498-1609438971=:22541 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT >> To what?  The Yahoo address is the only address the scout troop has? > > Copy that to Reply-To: and write a mangled From: that looks troopy but passes > DMARC. Just like MLMs do. Lists at MLMs have names that the subscribers will recognize, but the scout troop only has the Yahoo address. There are certainly kludges that one can apply to circumvent DMARC rejections, but this is a clear failure, an existing legitimate mail use that DMARC breaks. R's, John --0-907014498-1609438971=:22541-- From nobody Thu Dec 31 10:36: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 A7DF13A0E3F for ; Thu, 31 Dec 2020 10:36:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, 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=mtcc.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 DLU4MU_iY8CB for ; Thu, 31 Dec 2020 10:36:19 -0800 (PST) Received: from mail-pf1-x42d.google.com (mail-pf1-x42d.google.com [IPv6:2607:f8b0: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 8900C3A0E3D for ; Thu, 31 Dec 2020 10:36:19 -0800 (PST) Received: by mail-pf1-x42d.google.com with SMTP id h186so11595627pfe.0 for ; Thu, 31 Dec 2020 10:36:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mtcc.com; s=fluffulence; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=VRD5uNbcYaFizIhXNA5Sy9Z9jzcM6EZgMr18NWMMc0Q=; b=Hhhd8e9qiSCbswwN3v0/34wHlanHAw2B5YZMmSjVVMYb3De7V05V2+8ojQsRx6vWCZ 2nJlCPJ/o3D/My8mQUUZ6vBDNXM3fcIfT37iEX5D1ic3a6DP1AD5tC8rfC7qPXyqGY+q 8TI8SjBZhKZwaqbMzAiWbUkvXgyhpz7gmSsY1u8YAgg5Z8jTGjalsCNqYjFEL72r07rL e6gBsXbgba2H8YDppdyKaE0dM3sstka5pG9YBTN5DJ5jWsv6m+SyesqcbJ774dOMhtiX i5QHL/NoAM1lFhpYwauxrurglUG2hCH6qUOiqHlwt6QVBto6l0EGj2YPosowGSDJifUp lvNg== 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=VRD5uNbcYaFizIhXNA5Sy9Z9jzcM6EZgMr18NWMMc0Q=; b=ocBgCurTn8vU8pFpS4ks1OJ25L9ENHjN8GtrK8/YluU7pupGp+leX/ZznRP1KWwwrU wiAUloxd/o/V1832lB0BzB/Ck//SXJOhsMGmE++5EZqZngTkJEMXyFh6VMK0T+IMP/au Uu/iL1cF7cQEk/ywHRwv0KJkx3+/EzrtitHCs7WxlmHC+/azEfHAXD2GfouWOBMOhXa8 eUarer04UMlrdncwdWug+GHPP/eYYB+1NFz+rWw8P7Vs+6BOf9jVj13a9WxouFWx+n5I zzUa1j8rukcxaSvBhxzFi79byWo6DSeN+1xBZDDyQkhF/Z3yLuzRJy0sQ/LYM+VgzPnA NS9A== X-Gm-Message-State: AOAM5325vP4rqbPQhgzy0WS0pyBQ+K1YuB9PuzXKp8eCh8G8A4W73xSK hLdnQg7aMWo8o9BH8qxqXV7eObxwjThFgg== X-Google-Smtp-Source: ABdhPJxvAeikcLk+nk/Y3zXyWM6q/hkUobpcIVvH7h/82SfH1QAzv/0Lwq0E7xSGmvnWtiBbgjP9qg== X-Received: by 2002:a62:1b95:0:b029:19b:178f:84d7 with SMTP id b143-20020a621b950000b029019b178f84d7mr15519982pfb.70.1609439777482; Thu, 31 Dec 2020 10:36:17 -0800 (PST) Received: from mike-mac.lan (107-182-45-95.volcanocom.com. [107.182.45.95]) by smtp.gmail.com with ESMTPSA id p16sm11682702pju.47.2020.12.31.10.36.16 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 31 Dec 2020 10:36:16 -0800 (PST) To: dmarc@ietf.org References: <20201231160030.20AFB3EE7AD7@ary.qy> <4bd444a4-0c34-467a-cfcb-a8f7c14b723d@tana.it> <3999b617-b0e7-7341-93df-4a2ccea134e4@tana.it> <64cb14ed-322b-eecb-bed2-13349e19b833@taugh.com> From: Michael Thomas Message-ID: Date: Thu, 31 Dec 2020 10:36:15 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: <64cb14ed-322b-eecb-bed2-13349e19b833@taugh.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] Ticket #55 - Clarify legal and privacy implications of failure reports X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Dec 2020 18:36:21 -0000 On 12/31/20 10:22 AM, John R Levine wrote: >>> To what?  The Yahoo address is the only address the scout troop has? >> >> Copy that to Reply-To: and write a mangled From: that looks troopy >> but passes DMARC.  Just like MLMs do. > > Lists at MLMs have names that the subscribers will recognize, but the > scout troop only has the Yahoo address. > > There are certainly kludges that one can apply to circumvent DMARC > rejections, but this is a clear failure, an existing legitimate mail > use that DMARC breaks. > > The entire problem with catering to the long tail is that it is holding hostage better email security. We should stop doing that. There is no right to stasis forevermore. If the scouts email breaks, they can get somebody to fix it. They will thank us in the long run when scammers can't phish using them as a prop. Mike From nobody Thu Dec 31 11:25: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 B15FE3A0407 for ; Thu, 31 Dec 2020 11:25:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.849 X-Spam-Level: X-Spam-Status: No, score=-1.849 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iecc.com header.b=hisBjOa+; dkim=pass (2048-bit key) header.d=taugh.com header.b=nEycD8FT Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id npUWVj1L5ups for ; Thu, 31 Dec 2020 11:25:02 -0800 (PST) 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 F1A5E3A03FB for ; Thu, 31 Dec 2020 11:25:01 -0800 (PST) Received: (qmail 88290 invoked from network); 31 Dec 2020 19:25:00 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=158d4.5fee258c.k2012; bh=EGSovC36ARFBphbeQDZADxKQwrL8PeZcfcNEex7v3eE=; b=hisBjOa+iKs3T5xOaCgv+G5CGjn20bnkF+Jc46mP3tuv9/2YtPsbUovaX+p9oO7mleENwcMuJGK9gkDsBQyohcVB0edlVQ/+Kz5qA2cCOKoqfKWCP7gSDu/gtmZqXA7H9SqUvnkvoyfDPHiRb2S05gmRBeJRcU+SXwhSYkhpNK1peynaCbjBYZ4GKf3SiuGTj+o30tiR7yblUlLCxC6w6CXlKOlHYMFezaMmwspguzlrL+Sz3onqvkjgemR1LiktEtr20PEkS/AtHdvgRzsRZf64rGCGjskDJUh71UpT+Ns5dTYmq2sCSBW4TnUIKoN4zJ+a1KeXu1NMQfmVltNQoA== DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=158d4.5fee258c.k2012; bh=EGSovC36ARFBphbeQDZADxKQwrL8PeZcfcNEex7v3eE=; b=nEycD8FTw4F1PkQgMF1a1x34MK3FhcB+qcMPDlhGjLgjRfrrRLeayea/uhzs+cLSWwtMeXkEK8lp+Xr+dp+SCtZzyZYaiCIjk8YxHMKPYXhKLMLD5eQqsFUYmCoDW6jM8qDiGx34Sea7qppYJnFF2J3vcNFQeb3svwChtxuabgTSNXTNMeYdrIHZ1jo9IjFNxJlZ56IuQZ/8HRRxJRukyus7VEBX295S5F5gTp/mjFnxPCT43vgWsgzdKKI6tJzgX4ZJDYiqP7FVDTsT0V5E/0lJ6H++QzzCfY+kdDfQLgU9oVvYDsFeAYGTcnVsbezf2IDS8j33FvAo1mT2Xf4W0g== 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 Dec 2020 19:25:00 -0000 Received: by ary.qy (Postfix, from userid 501) id 1B3483F0176B; Thu, 31 Dec 2020 14:24:59 -0500 (EST) Date: 31 Dec 2020 14:24:59 -0500 Message-Id: <20201231192500.1B3483F0176B@ary.qy> From: "John Levine" To: dmarc@ietf.org Cc: todd.herr@valimail.com In-Reply-To: Organization: Taughannock Networks X-Headerized: yes Cleverness: minimal Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] Ticket #80 - DMARCbis Should Have Clear and Concise Definition of DMARC X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Dec 2020 19:25:04 -0000 In article you write: >-=-=-=-=-=- > >In mid-November, I shared some proposed text for new Abstract and >Introduction sections - >https://mailarchive.ietf.org/arch/msg/dmarc/wNE-cvIWQ3PXrM-42SozSocnnxs/ > >Dave Crocker submitted some suggestions on-list, and I noodled a bit with >the text myself, and submit the following for your collective consideration: I have a few minor editorial tweaks to suggest but they can wait. I hink we should use this text. -- snippo -- From nobody Thu Dec 31 20:11: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 F142F3A0C03 for ; Thu, 31 Dec 2020 20:11:49 -0800 (PST) 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 3Km9pQquIC1F for ; Thu, 31 Dec 2020 20:11:48 -0800 (PST) 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 3F0F13A0C00 for ; Thu, 31 Dec 2020 20:11:48 -0800 (PST) Received: by mail-vs1-xe32.google.com with SMTP id s2so10778281vsk.2 for ; Thu, 31 Dec 2020 20:11:48 -0800 (PST) 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=UtwvjliP89wADB/WYy/CTC2AiIFLo/e3rXh3+p737wI=; b=W+IhBni8kJUhaLW7OR6xB1CpiWCobPCAqmGp0+jMXIFq2P3er2DX9rGJEF/ukt8G7m 5nZYBfPzdCmyJeg3kyArWJG5l2yG1RZEm/5Do8yN5Dygr0N3yXzf8a8Yzt9Ssv3z6uuq fnaYYZPJmCk+MIex/RWu25iRKStMntzCyRd9GsgPU/evrYgXdyAiO35YaTOFcP6RS0RS Nl/BJGnY2sMqxt+wlWdZO+HJnFMG6CCMnnOdj382X26lE3VkJj1ZL2HUQP/NwqtrV5cl PZjm58hdruVH+1V1gByta1yfK9qCOzHOVYEWASBM5YDNAhUOVFDYN8oyBJVk+PnfWfXJ Iq+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=UtwvjliP89wADB/WYy/CTC2AiIFLo/e3rXh3+p737wI=; b=T4Ufm+oioB+wXjTD0Dxhp6tsnTwpvhl7C1Z5Rf6/oz7x2IOlDqi7wk4MEFZlzmC9Eu ScOlcRjtsns5qZFssOuuOPVUypg9XrJWoHs/zOE6wuJDefs+zhRNw688P5fYPwhzBapy vtpP/Ga76zIOHfPxssX2nZxqKbaffRxTbMAuRF604lVTxTi6vvHRdxYeOZdlYruKSvh6 neP84BGXhqJoMq95XTdP/xlIH10eUOvay8xKOiaIQ1iqW5of1WM4o1Bu8WlMU7Pu1qd6 m4ha5e01CLFW+JAmDUUmlZschMHE4QzycJvrunmGmzDf3RE2tSUEs9U6IGmByuvvekvL 683A== X-Gm-Message-State: AOAM533DzNLkQIlYXcytzFP9LP6lvHUpCFU2FlPJ78DJuhXXD4Xg9nl9 r3gSoujq1oFuBOG6dO3C9wCJomtTHei7lyZqdyo= X-Google-Smtp-Source: ABdhPJzZC8EEo0YkwnXR++fiK/FrzOJ61+UGch/h21tag3ts3SvI9lOo0iS2Gy7x4VeINSzNYvOT8EXjfWzRHc9CQKo= X-Received: by 2002:a67:f14f:: with SMTP id t15mr38003785vsm.0.1609474307084; Thu, 31 Dec 2020 20:11:47 -0800 (PST) MIME-Version: 1.0 References: <9f6782b1-e85b-1a9c-9151-98feff7e18ea@mtcc.com> <5588dbbe-b876-ed80-c80f-792380e3718f@mtcc.com> <54dd9978-bcd1-6757-ad27-dcef6db6e5f7@mtcc.com> <937f1019-a028-308d-2a0f-1e720fd49dcd@mtcc.com> <72e20c17-e991-e82a-9120-a27097e3ac58@mtcc.com> <7863d250-f56a-1fe1-44ee-fbc7486d48b4@mtcc.com> <0b0c0c7c-f374-6718-5071-b5e9b0d67db3@mtcc.com> In-Reply-To: <0b0c0c7c-f374-6718-5071-b5e9b0d67db3@mtcc.com> From: "Murray S. Kucherawy" Date: Thu, 31 Dec 2020 20:11:34 -0800 Message-ID: To: Michael Thomas Cc: Seth Blank , IETF DMARC WG , Dotzero Content-Type: multipart/alternative; boundary="0000000000005954f305b7cef07a" Archived-At: Subject: Re: [dmarc-ietf] auth-res vs. dmarc X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jan 2021 04:11:50 -0000 --0000000000005954f305b7cef07a Content-Type: text/plain; charset="UTF-8" On Wed, Dec 30, 2020 at 9:16 AM Michael Thomas wrote: > Later? How much later? Looking at the open tickets it looks you have > about 5 more years of "later". And I would say the chairs teeing up > tickets would be a far more efficient means of driving the process than > shutting down discussions that will become tickets. That other thread on > privacy should have been closed out weeks ago. > The alternative is to have all of those discussions open at the same time. It's not hard to imagine a way to ensure even less progress than we're making now. I believe there are several separate issues: > > [...] > > 2) Auth-res process-wise is an orphan with no means of discussing it in > any working group even though it's standards track and has issues > requiring coordination with this working group > I don't understand the basis for this assertion. There are many standards track documents that are not historic but don't currently have a working group developing them. I don't think of them as orphans. If the IETF has work to do on one of them, we either spin up a working group to do the work, or an AD can sponsor the work, or an existing WG can negotiate to extend its charter to cover the work. This WG already extended RFC 7601 to become RFC 8601. It could, in theory, do so again. 3) The fundamental question that Ned brought up which is whether > Auth-res is a protocol at all. If it's really just a debugging tool to > be use by humans, it should definitely just be informational, and > probably historic. Either Auth-res is useful and supported or not and > should be killed > This is the first time I've heard that it's not useful. If that were the case, I wonder why it's gone through four iterations (RFC 5451, then RFC 7001, then RFC 7601, and now RFC 8601). 4) Should DMARC require a normative Authentication-Results Requirements > section? This process-wise would solve the problem of auth-res in (2) > and shift the specification of that normative text back to the document > that is affected by it, letting Auth-res just be a transport vehicle so > that it doesn't require yet another working group-less update. That is > what we should have done from the start, but auth-res is an accident of > history. > Section 6.7 of RFC 7489 recommends use of A-R. If the WG chooses to change that to a MUST, that seems reasonable to me. -MSK --0000000000005954f305b7cef07a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Dec 30, 2020 at 9:16 AM Michael T= homas <mike@mtcc.com> wrote:
=
Later? How much later? Looking at the open tickets it looks you hav= e
about 5 more years of "later". And I would say the chairs teeing = up
tickets would be a far more efficient means of driving the process than shutting down discussions that will become tickets. That other thread on privacy should have been closed out weeks ago.

The alternative is to have all of those discussions open at the sam= e time.=C2=A0 It's not hard to imagine a way to ensure even less progre= ss than we're making now.

I believe there are several separate issues:

[...]

2) Auth-res process-wise is an orphan with no means of discussing it in any working group even though it's standards track and has issues
requiring coordination with this working group

I don't understand the basis for this assertion.
=
There are many standards track documents that are not histor= ic but don't currently have a working group developing them.=C2=A0 I do= n't think of them as orphans.=C2=A0 If the IETF has work to do on one o= f them, we either spin up a working group to do the work, or an AD can spon= sor the work, or an existing WG can negotiate to extend its charter to cove= r the work.

This WG already extended RFC 7601 to b= ecome RFC 8601.=C2=A0 It could, in theory, do so again.

<= /div>
3) The fundamental question that Ned brought up which is whether
Auth-res is a protocol at all. If it's really just a debugging tool to =
be use by humans, it should definitely just be informational, and
probably historic. Either Auth-res is useful and supported or not and
should be killed

This is the first time= I've heard that it's not useful.=C2=A0 If that were the case, I wo= nder why it's gone through four iterations (RFC 5451, then RFC 7001, th= en RFC 7601, and now RFC 8601).

4) Should DMARC require a normative Authentication-Results Requirements section? This process-wise would solve the problem of auth-res in (2)
and shift the specification of that normative text back to the document that is affected by it, letting Auth-res just be a transport vehicle so that it doesn't require yet another working group-less update. That is =
what we should have done from the start, but auth-res is an accident of history.

Section 6.7 of RFC 7489 recomm= ends use of A-R.=C2=A0 If the WG chooses to change that to a MUST, that see= ms reasonable to me.

-MSK

--0000000000005954f305b7cef07a--