Re: [dmarc-ietf] auth-res vs. dmarc

Seth Blank <seth@valimail.com> Wed, 30 December 2020 16:42 UTC

Return-Path: <seth@valimail.com>
X-Original-To: dmarc@ietfa.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 <dmarc@ietfa.amsl.com>; 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 <dmarc@ietfa.amsl.com>; 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 <dmarc@ietf.org>; Wed, 30 Dec 2020 08:42:18 -0800 (PST)
Received: by mail-vs1-xe2c.google.com with SMTP id x26so8851703vsq.1 for <dmarc@ietf.org>; 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> <CAHej_8m0OWsTt+tcSgUh+Fxu=HH_57nsb2O1Q_fgA2453ceh4g@mail.gmail.com> <140485eb-020f-4406-3f2f-e2c475ea51e5@mtcc.com> <CAHej_8mApfoF2ORgL+DoYTanrdhMjvT9H27kORwLKCQc1C9sRw@mail.gmail.com> <5588dbbe-b876-ed80-c80f-792380e3718f@mtcc.com> <CAHej_8=kW_t_JkOxUud1Uz8+PrbMh5CfwfxZK=mhe0wjW8wQpw@mail.gmail.com> <54dd9978-bcd1-6757-ad27-dcef6db6e5f7@mtcc.com> <CAHej_8kCi=7oqojDH_rbjn7kRg-PTDJWLgcKTGK9z-baUnKeMw@mail.gmail.com> <ef32de1e-d47e-1d0f-3cec-5994c7fdb7ae@mtcc.com> <CAHej_8kjSsQK_XEbdjWzV5npa29YjGadzD06Fmx3QLB4p+n_Cg@mail.gmail.com> <937f1019-a028-308d-2a0f-1e720fd49dcd@mtcc.com> <d8014c2a-c1c9-9eac-e64a-5f285bab7fd3@tana.it> <CAHej_8mgYr9ERAxmup+keZT5u8L+qgCxcSLH7Z=BEuZLouttpg@mail.gmail.com> <72e20c17-e991-e82a-9120-a27097e3ac58@mtcc.com> <CAHej_8=6huc-N4ymDTOWZXHGjQQ-3RFDdomRzmGp4kOseHckMQ@mail.gmail.com> <7863d250-f56a-1fe1-44ee-fbc7486d48b4@mtcc.com> <CAJ4XoYdMdaE92UOrXvcAqm2iou+PCGg_uzHUsmBsYRe1PivBJw@mail.gmail.com> <ac7b7b32-c544-60f2-1a6a-a5a210ac72ed@mtcc.com>
In-Reply-To: <ac7b7b32-c544-60f2-1a6a-a5a210ac72ed@mtcc.com>
From: Seth Blank <seth@valimail.com>
Date: Wed, 30 Dec 2020 08:42:06 -0800
Message-ID: <CAOZAAfNRgxJaO-TJcnvqJTqOCsixzLJVK+vSH-Av+FezY=texw@mail.gmail.com>
To: Michael Thomas <mike@mtcc.com>
Cc: Dotzero <dotzero@gmail.com>, IETF DMARC WG <dmarc@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000a8d5a805b7b130fb"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/-j2T2wLBuZLcVNoIU1vuxsdXJL0>
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\)" <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>
X-List-Received-Date: Wed, 30 Dec 2020 16:42:20 -0000

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 <mike@mtcc.com> 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.