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
- [dmarc-ietf] auth-res vs. dmarc Michael Thomas
- Re: [dmarc-ietf] auth-res vs. dmarc Todd Herr
- Re: [dmarc-ietf] auth-res vs. dmarc Hector Santos
- Re: [dmarc-ietf] auth-res vs. dmarc Michael Thomas
- Re: [dmarc-ietf] auth-res vs. dmarc Michael Thomas
- Re: [dmarc-ietf] auth-res vs. dmarc Todd Herr
- Re: [dmarc-ietf] auth-res vs. dmarc Michael Thomas
- Re: [dmarc-ietf] auth-res vs. dmarc Todd Herr
- Re: [dmarc-ietf] auth-res vs. dmarc Laura Atkins
- Re: [dmarc-ietf] auth-res vs. dmarc Michael Thomas
- Re: [dmarc-ietf] auth-res vs. dmarc Todd Herr
- Re: [dmarc-ietf] auth-res vs. dmarc Michael Thomas
- Re: [dmarc-ietf] auth-res vs. dmarc Todd Herr
- Re: [dmarc-ietf] auth-res vs. dmarc Michael Thomas
- Re: [dmarc-ietf] auth-res vs. dmarc Douglas Foster
- Re: [dmarc-ietf] auth-res vs. dmarc Kurt Andersen (b)
- Re: [dmarc-ietf] auth-res vs. dmarc Douglas Foster
- Re: [dmarc-ietf] auth-res vs. dmarc Alessandro Vesely
- Re: [dmarc-ietf] auth-res vs. dmarc Alessandro Vesely
- Re: [dmarc-ietf] auth-res vs. dmarc Todd Herr
- Re: [dmarc-ietf] auth-res vs. dmarc Michael Thomas
- Re: [dmarc-ietf] auth-res vs. dmarc Michael Thomas
- Re: [dmarc-ietf] auth-res vs. dmarc Michael Thomas
- Re: [dmarc-ietf] auth-res vs. dmarc Dotzero
- Re: [dmarc-ietf] auth-res vs. dmarc Laura Atkins
- Re: [dmarc-ietf] auth-res vs. dmarc Michael Thomas
- Re: [dmarc-ietf] auth-res vs. dmarc Todd Herr
- Re: [dmarc-ietf] auth-res vs. dmarc Todd Herr
- Re: [dmarc-ietf] auth-res vs. dmarc Michael Thomas
- Re: [dmarc-ietf] auth-res vs. dmarc Todd Herr
- Re: [dmarc-ietf] auth-res vs. dmarc Michael Thomas
- Re: [dmarc-ietf] auth-res vs. dmarc Michael Thomas
- Re: [dmarc-ietf] auth-res vs. dmarc Dotzero
- Re: [dmarc-ietf] auth-res vs. dmarc Michael Thomas
- Re: [dmarc-ietf] auth-res vs. dmarc Dotzero
- Re: [dmarc-ietf] auth-res vs. dmarc Todd Herr
- Re: [dmarc-ietf] auth-res vs. dmarc Michael Thomas
- Re: [dmarc-ietf] auth-res vs. dmarc Seth Blank
- Re: [dmarc-ietf] auth-res vs. dmarc Hector Santos
- Re: [dmarc-ietf] auth-res vs. dmarc Michael Thomas
- Re: [dmarc-ietf] auth-res vs. dmarc Seth Blank
- Re: [dmarc-ietf] auth-res vs. dmarc Alessandro Vesely
- Re: [dmarc-ietf] auth-res vs. dmarc Todd Herr
- Re: [dmarc-ietf] auth-res vs. dmarc Michael Thomas
- Re: [dmarc-ietf] auth-res vs. dmarc Alessandro Vesely
- Re: [dmarc-ietf] auth-res vs. dmarc Michael Thomas
- Re: [dmarc-ietf] auth-res vs. dmarc Seth Blank
- Re: [dmarc-ietf] auth-res vs. dmarc Michael Thomas
- Re: [dmarc-ietf] auth-res vs. dmarc Seth Blank
- Re: [dmarc-ietf] auth-res vs. dmarc Alessandro Vesely
- Re: [dmarc-ietf] auth-res vs. dmarc Alessandro Vesely
- Re: [dmarc-ietf] auth-res vs. dmarc John Levine
- Re: [dmarc-ietf] auth-res vs. dmarc Murray S. Kucherawy