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

Michael Thomas <mike@mtcc.com> Wed, 30 December 2020 16:30 UTC

Return-Path: <mike@fresheez.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 08FC93A0962 for <dmarc@ietfa.amsl.com>; 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 <dmarc@ietfa.amsl.com>; 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 <dmarc@ietf.org>; Wed, 30 Dec 2020 08:30:49 -0800 (PST)
Received: by mail-pj1-x1033.google.com with SMTP id n3so2190212pjm.1 for <dmarc@ietf.org>; 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 <dotzero@gmail.com>
Cc: IETF DMARC WG <dmarc@ietf.org>
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>
From: Michael Thomas <mike@mtcc.com>
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: <CAJ4XoYdMdaE92UOrXvcAqm2iou+PCGg_uzHUsmBsYRe1PivBJw@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------5629053CECE81519042826D9"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/EOk3y_fO0iSd-1aNjOdE4t8_vLQ>
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:30:51 -0000

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