Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field

Scott Kitterman <sklist@kitterman.com> Sun, 27 September 2020 18:23 UTC

Return-Path: <sklist@kitterman.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 712873A12C6 for <dmarc@ietfa.amsl.com>; Sun, 27 Sep 2020 11:23:02 -0700 (PDT)
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=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=kitterman.com header.b=OCBo2GZF; dkim=pass (2048-bit key) header.d=kitterman.com header.b=USpXWMcl
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jAbfWHwRf0D2 for <dmarc@ietfa.amsl.com>; Sun, 27 Sep 2020 11:23:00 -0700 (PDT)
Received: from interserver.kitterman.com (interserver.kitterman.com [64.20.48.66]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 95A963A12C5 for <dmarc@ietf.org>; Sun, 27 Sep 2020 11:23:00 -0700 (PDT)
Received: from interserver.kitterman.com (interserver.kitterman.com [64.20.48.66]) by interserver.kitterman.com (Postfix) with ESMTPS id 49353F80232 for <dmarc@ietf.org>; Sun, 27 Sep 2020 14:22:59 -0400 (EDT)
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903e; t=1601230979; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=YQXA1qIaT9Ej5rdI1G4jcio5dnBmd9dJxdfLTjIDm3k=; b=OCBo2GZF6UveBHcP1Skz3hVrMlawP5RrwXRTbJrfPUms4ZyIPNZhTLBzluLf+rAfV746V eQRhE6vS0RUTGcYAQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903r; t=1601230979; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=YQXA1qIaT9Ej5rdI1G4jcio5dnBmd9dJxdfLTjIDm3k=; b=USpXWMcleeLqJtAz1LpIJ3TI/f0crbtQl0pBQPtrBFey1ao9OtwDSBTiBJWqNNKK7/a4/ /RkEi1a560iyePamWbi+BUFFVLKuLGx0PA1plCaPjN4ab3GW8U2DX43nqSkM2Xqz5fSbAA2 fNSWKl8TTyowAi6uQnqHi1x0TNU4t2DdsAPXNl6LFr0RQnZGCyFTDDemAXXbD7iFAs65+hW LoSE+PzVRpo945RFKna8QwSFKvNJVv0rWecE2GFV1KjnccRAtcxVdp7McRHMK6sNXtrVn5W /wo5L8XgWC7EUF+8FOy+j2jCo7Uk9qLUi6aTrm2dSxh7O+ruKRLSa+Vkx60Q==
Received: from zini-1880.localnet (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) by interserver.kitterman.com (Postfix) with ESMTP id 1E0A5F801A2 for <dmarc@ietf.org>; Sun, 27 Sep 2020 14:22:59 -0400 (EDT)
From: Scott Kitterman <sklist@kitterman.com>
To: dmarc@ietf.org
Date: Sun, 27 Sep 2020 14:22:58 -0400
Message-ID: <5069099.lO0Lvmlme3@zini-1880>
In-Reply-To: <20200927171611.838B321D9BAD@ary.qy>
References: <20200927171611.838B321D9BAD@ary.qy>
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/1XJSVlotfv6nzOW3Fd0Am9eP47E>
Subject: Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field
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: Sun, 27 Sep 2020 18:23:02 -0000

On Sunday, September 27, 2020 1:16:11 PM EDT John Levine wrote:
> In article <4004580.HQKp4RnRq6@zini-1880> you write:
> >I don't think this his helpful.  If something like this is going to be
> >standardized, it shouldn't be called DMARC because it's not.
> 
> We (the generic we) seem to have a fundamendal disconnect about what
> DMARC is for.
> 
> One group appears to believe it's about what users see in their inbox,
> to ensure that the address on the From: line matches the actual
> author.

Speaking at least for myself, not quite.  I think it's more about what users 
don't see than what they see.  I think most everyone agrees DMARC is to 
support filtering, I think the question is about how.

DMARC defines a policy set with the goal that receivers will act on that 
policy.  Specifically that receivers will reject/quarantine mail that fails 
DMARC for domains that have published such restrictive policies.

The approach defined is mechanical, not statistical.  I think that's the key 
difference.  Is it about specific policy enforcement, or is it just one more 
token for a bayesian network?

> The other group appears to believe it's a filtering signal that mail
> systems mix into the filtering process they apply between the time the
> mail arrives at the MX and the time the users sees it.

This seems to me to be an odd view because no RFC is needed to use From and 
it's relationship to either DKIM signing domain or SPF validated Mail From.  
Feeding data into an algorithm has no interoperability requirements.

That doesn't mean one can't use the data this way, because anyone can that 
wants to can.  That doesn't make it the specified protocol.

> I suppose both are right to some extent, but they have very different
> implications for the design.

Agreed.  Maybe it would help if someone who takes the latter view would 
explain what they think RFC 7489, Section 6.6.2, Step 6 is for:

>    6.  Apply policy.  Emails that fail the DMARC mechanism check are
>        disposed of in accordance with the discovered DMARC policy of the
>        Domain Owner.  See Section 6.3 for details.

I don't think that says "then toss the results into your classifier".

Scott K