Re: [dmarc-ietf] DMARC alignment conflicts with RFC 5322 on the use of the From and Sender header fields

Brandon Long <blong@google.com> Tue, 02 June 2020 17:12 UTC

Return-Path: <blong@google.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 2ADA03A0CE3 for <dmarc@ietfa.amsl.com>; Tue, 2 Jun 2020 10:12:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.6
X-Spam-Level:
X-Spam-Status: No, score=-17.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 7VUsxnAoEiAP for <dmarc@ietfa.amsl.com>; Tue, 2 Jun 2020 10:12:06 -0700 (PDT)
Received: from mail-vs1-xe41.google.com (mail-vs1-xe41.google.com [IPv6:2607:f8b0:4864:20::e41]) (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 C02C43A0CD6 for <dmarc@ietf.org>; Tue, 2 Jun 2020 10:12:05 -0700 (PDT)
Received: by mail-vs1-xe41.google.com with SMTP id c1so2448939vsc.11 for <dmarc@ietf.org>; Tue, 02 Jun 2020 10:12:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=2abeTZTlV438+1OIRubP2Rf9vvgdpF+4BxYRR6nL7Bw=; b=Iima5ZNZhqiMzLSrzeH6KgHjpWT/qI2zp3AjztkC//Ir4A6VLL7RaM/eqlM82NizpL IWWlE6wvUaeG13zTqayCYwxLaKGoIREFr15+Fh9ckmMGrjvRQhgnneJwMUcztQL6M40S o5U2oqzZHQpSlhGKeOTslCmEfMTYVI2MQ9h7PaSb/j57bRlZuWonmbY4AOTJb3PyBZBI IUHryW9Z+hWcu4ynNBKuP3/HDaiP5nv7PJ8jOCsJaLUazRm919x+ZHurjY7L+mGraaHY 9rQ1xR61MOevXZN4hb1BbRjoAm8XFOUJp95iXrf2IgayxHUhmN6bu962IfQJGcQxM/00 BaMw==
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=2abeTZTlV438+1OIRubP2Rf9vvgdpF+4BxYRR6nL7Bw=; b=dDcctaKRrMM4hUelWv8lAK+epuWwZ8iNItI8Z1Vw5sf1aPRBGVIbx21hofkWhTkY99 JC7hRQgiM0fLkzCVws05CiKpcpC1bacy3OR3u8Aia3L0Xmcmx/x5pIFtxA8H/ZCi1tL3 Dr5ckOjK8MkEFSsNzzEADpzYaFNOTQWRntwPYAcsZoHHmCgYWKYnugV1NuzFeTgQ3kn/ Cl0h6+7+OP120XDk05skzdqASkoCQL0i9ubxGnUHz/5f89AmxKqLL9Zoo2EEcuRlThPG 8vooTCfsG7EYMCp9i7/h+gLZ3nEXw++KNNDtQJXlasfTnDtTpBqtMh9afbDwdQB53qxA 0obg==
X-Gm-Message-State: AOAM532YnuG1CDPAfx1QNw3IeQ9Upa26l1EMTF13pGKfr44/+SX+odaR won6XgVViIzGHxnER/ayZDyJdCcMv0Z50aj0pGkQK4A=
X-Google-Smtp-Source: ABdhPJygS67ljS6WgcDjPK3IWO7N1NMNvLxMkWnV1q4YXQhpBAk9BsW5tkLrqqQLMZVS9DydiybXWihx3AVEe5GN/x8=
X-Received: by 2002:a05:6102:36b:: with SMTP id f11mr5111368vsa.124.1591117924095; Tue, 02 Jun 2020 10:12:04 -0700 (PDT)
MIME-Version: 1.0
References: <DM5PR0601MB367115AD49513EAF3953716CF68B0@DM5PR0601MB3671.namprd06.prod.outlook.com> <18441e8d-cf87-053e-4957-7b9d6ea9690c@gmail.com>
In-Reply-To: <18441e8d-cf87-053e-4957-7b9d6ea9690c@gmail.com>
From: Brandon Long <blong@google.com>
Date: Tue, 02 Jun 2020 10:11:50 -0700
Message-ID: <CABa8R6s7Lh_nihfH4Y8=JFCDFL6T_iEd+dBf7C=iW+5S3K4i3A@mail.gmail.com>
To: Dave Crocker <dcrocker@gmail.com>
Cc: "dmarc@ietf.org" <dmarc@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000aa168a05a71d02a3"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/x-JxnmUBDU_pdu9f0bDY7w90sOA>
Subject: Re: [dmarc-ietf] DMARC alignment conflicts with RFC 5322 on the use of the From and Sender header fields
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: Tue, 02 Jun 2020 17:12:15 -0000

On Tue, Jun 2, 2020 at 10:01 AM Dave Crocker <dcrocker@gmail.com> wrote:

> On 6/2/2020 9:44 AM, Jesse Thompson wrote:
> > I'm relaying these DMARC questions/concerns on behalf of an email admin
> at another university.  I quickly searched this list's archives for the
> Sender header vs DMARC alignment issue and don't see much aside from a
> conversation in May 2015.  Is it worth further discussion and/or an issue
> in Trac?  I think I know the answer to the second concern, but I'll defer
> to people more adept at explaining the nuance.
> >
> > See below...
> >
> > Thanks,
> > Jesse Thompson
> > UW-Madison
> >
> > "
> > I don't see on the list of issues the most fundamental problem of DMARC,
> namely that it conflicts with RFC 5322 on the use of the From and Sender
> header fields [1] and possibly with RFC 6326 as to the significance of DKIM
> fail [2].  The former is the more serious problem. Making DMARC alignment
> part of a standard for Internet messages requires a revision of RFC 5322.
> I'd love to see this resolved.
>
>
> As one of the folk who created the Sender: construct in RFC 733, I'll
> suggest that the concern raised here has merit, though dealing with the
> fact isn't straightforward.  It's an issue I've been wrestling with for
> a couple of years.
>
> In reality, all of the current email anti-abuse authentication methods
> concern the email operator, not the author.
>
> The problem is that, in the message, the only identifier that is
> reliably present is the rfc5322.From field email address.
>
> The underlying design choice in RFC733 -- 45 years ago -- was in making
> Sender: optional when it's content is the same as the From: field.  It
> never occurred to us that one of them might need changing along the
> handling path.  The lesson to future designers is to strongly resist
> conflating otherwise-independent semantics for "efficiency".
>
> DMARC enforcement requires that the DKIM/SPF domain be the same as the
> author From:.  That is, the folk doing email operations have to be able
> to sign the DMARC aligned domain.
>
> Hence the From: field is now really the Sender: field.  The From: field
> fixup hacks that are needed by intermediaries, to avoid DMARC-based
> rejections, makes this fact painfully clear, even as they serve to
> undermine recipient use of the From field for author-related message
> management.
>
> Given the depth and momentum of DMARC's effects, I don't think it's
> realistic to try to fix this via changes to the From: field.
>
> The only suggestion I've been able to formulate is:  create a new field,
> such as Author:.
>
> (Give it a simple, clean, appropriate name, rather than something like
> Original-From.)
>

And if the mail client displays the Author, then we're kind of back to
square one
with displaying unvalidated data to the user.

Which is to say, DMARC is just policy, but what makes it different from the
previous policy attempts
is that it requires the visible author/operator to be authenticated.

There's no reason that DMARC couldn't have included the sender or tried to
have some kind of
PRA like spf v2... but that's not the goal.

At some point, you're going up against the existing mail client design and
of course
how users act, and of course all of that is messy.  The "clean" strictness
and mechanical nature
of DMARC is ultimately up against the fuzzy ux design and fuzzier humans.

On top of that, the author domains basically want to control who can send
on their behalf, which is
a reasonable goal as well.

Brandon