Re: [dmarc-ietf] Overall last-call comments on DMARC

Jim Fenton <fenton@bluepopcorn.net> Thu, 04 April 2024 19:55 UTC

Return-Path: <fenton@bluepopcorn.net>
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6976BC1519AF for <dmarc@ietfa.amsl.com>; Thu, 4 Apr 2024 12:55:12 -0700 (PDT)
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, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=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 ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LAOUqKdIlt5z for <dmarc@ietfa.amsl.com>; Thu, 4 Apr 2024 12:55:08 -0700 (PDT)
Received: from v2.bluepopcorn.net (v2.bluepopcorn.net [IPv6:2607:f2f8:a994::2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52C20C1519BA for <dmarc@ietf.org>; Thu, 4 Apr 2024 12:54:31 -0700 (PDT)
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=xtGmZQ8qVfAFMrVPxo7zPZ30JFftwerUdfYmP3a+p6Q=; b=YTiwCT2uPb/LyBMw+WdOJq/EBK dGEeWEZfs1RBGCrQQTiX+84RJv7RaRs48pfOO4omzxIsVB3Y+I6EC0rt9kXWRWWLuAlEAl4Xj6G75 56R4iAP7UkI3oROZWOJH9nLJZb4RN67a6j97dOVByxCUUGWsBUo7pUvCeTmw4OjQiRFA=;
Received: from [2601:647:6801:6430:f11c:ef34:b355:bca9] (helo=[10.10.20.233]) by v2.bluepopcorn.net with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from <fenton@bluepopcorn.net>) id 1rsTAC-00037y-Mx; Thu, 04 Apr 2024 12:54:30 -0700
From: Jim Fenton <fenton@bluepopcorn.net>
To: "Murray S. Kucherawy" <superuser@gmail.com>
Cc: IETF DMARC WG <dmarc@ietf.org>
Date: Thu, 04 Apr 2024 12:54:29 -0700
X-Mailer: MailMate (1.14r5852)
Message-ID: <80DC41F0-7AF9-4C08-9374-37626FCA2BB3@bluepopcorn.net>
In-Reply-To: <CAL0qLwbUzscPbk1mGj-c9fPYtMu+0VmMOm1KR4sGOrY6xapCCA@mail.gmail.com>
References: <CFEA2796-9213-4847-836B-81E8770973F5@bluepopcorn.net> <5208da1b-ecfb-4d41-8506-a734a27ab3a0@tana.it> <CAL0qLwbnSe77Wdt+M8bi2pBmZFCZjDUQc6je9bjCzP5TQ0N6XA@mail.gmail.com> <49859572-18a4-483b-bb99-62c1c231896e@tana.it> <CAL0qLwZc6idmMra11pVx2bbtk2Em9-vy6+962M7jDWOMnP+UHQ@mail.gmail.com> <1ee6df39-a622-4060-83db-bcc9a7a835d4@tana.it> <CAL0qLwYX_D7S_-Vn9RwwRzwyNO=8=3UVqbP8rz3SCWG4dvGZig@mail.gmail.com> <f5f55a39-127d-4a84-a66b-950379ecb013@tana.it> <CAL0qLwZzfnDA=7bwCu26S1SJPEE3hBq929674hH6naKXWuyh5g@mail.gmail.com> <ebf343ed-ee60-47b0-a02f-8518a8369bb0@tana.it> <CAL0qLwagtzjYYJmyyGpMeMTtKLtYyk_JjagkXGtscvN61kSDbw@mail.gmail.com> <CAH48ZfyKE6n2Q_GfW8oZv9y=MxOBV8sRPPMPV8akHdu6W_jn1A@mail.gmail.com> <CAL0qLwbt7A-9dUGphs5KLUhygYEd+4aY4Jr10efKpHZXAqMfmA@mail.gmail.com> <CAJ4XoYc5HYHE0EGhFw9jef3JXPQ5HKdUoZf8RD+YqzepHsWFmA@mail.gmail.com> <CAL0qLwbUzscPbk1mGj-c9fPYtMu+0VmMOm1KR4sGOrY6xapCCA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/TQLbAZbmWdQPnYfzB0AcjMpJ3lE>
Subject: Re: [dmarc-ietf] Overall last-call comments on DMARC
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.39
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: Thu, 04 Apr 2024 19:55:12 -0000

On 4 Apr 2024, at 12:08, Murray S. Kucherawy wrote:

> On Thu, Apr 4, 2024 at 12:02 PM Dotzero <dotzero@gmail.com> wrote:
>
>>
>>
>>>
>>> My overall point is that this thread makes it seem like we're not putting
>>> forward a complete solution.  It feels a lot more like a proposed standard
>>> that for its clear success depends on a bunch of other things that range
>>> from experimental to abstract to undefined.  And if that's a correct
>>> summary, I'm asking if that's what we really want to do.  It seems a little
>>> haphazard, like we're scrambling to tie together the loose ends of a movie
>>> plot.  We need to do a good job of bringing our audience to as solid a
>>> conclusion as possible, or the critics' reviews might not come out well.
>>>
>>
>> My response to your statement "... this thread makes it seem like we're
>> not putting forward a complete solution." is a complete solution to what?
>> It seems like people are trying to throw in everything but the kitchen
>> sink, including new proposals and rehashing old issues that were supposedly
>> settled, as we go through last call.
>>
>
> Yes, that's part of what I'm observing.  It's possibly a form of scope
> creep, and indeed "We should stop that" is one valid response.  :-)

I don’t think it’s scope creep at all. The WG charter puts “Review and refinement of the DMARC specification” in phase III, after “Specification of DMARC improvements to support indirect mail flows”. It seems clear to me that standards-track DMARC needs to incorporate those improvements.

IESG accepted ARC as an improvement to support indirect mail flows, and I think a complete solution needs to incorporate that. I wish there were better data to support advancing ARC to standards track, and not just from Google (it has to work for smaller players as well).

But I am troubled by the possibility that ARC might require domain reputation to avoid ARC header fields supporting From address spoofing. One reason it might work for Google is because they’re big enough to derive their own domain reputation. We’ve not had success with domain reputation at internet scale.

-Jim