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

Dotzero <dotzero@gmail.com> Tue, 02 June 2020 17:35 UTC

Return-Path: <dotzero@gmail.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 E59523A0CE5 for <dmarc@ietfa.amsl.com>; Tue, 2 Jun 2020 10:35:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 EOfe0zo3ZLsi for <dmarc@ietfa.amsl.com>; Tue, 2 Jun 2020 10:35:13 -0700 (PDT)
Received: from mail-wm1-x330.google.com (mail-wm1-x330.google.com [IPv6:2a00:1450:4864:20::330]) (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 5FDAC3A0CD9 for <dmarc@ietf.org>; Tue, 2 Jun 2020 10:35:13 -0700 (PDT)
Received: by mail-wm1-x330.google.com with SMTP id g10so3727434wmh.4 for <dmarc@ietf.org>; Tue, 02 Jun 2020 10:35:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=MqzBDHWP8aRQEnSW6FJxPYmJCxZOyPa7lgY6F8gpQzs=; b=qgBjzrUFbZKf0A4i4l1atwHPcDMActaC18jxte33ZaTvbOsJ1tXTtt0qTyDa798g5U pzEpbMJEikwDekaLwkHHutSOOnJoZvOcrWx8sVPkzTRmXPE17FI3h7XAQl3Ag5nGsiA6 DTjH2KleZCwkl0fGmU3vCt8hXMXgqZVpB23uKEVgN0bOw1XvKD/KIQijayUSvVu4Mmnf 4RUmQFS0XlNvpBOO3RYQzlcCL61e+p/dLQZTNLr+kxVBCL4AIiyxlnBwEHc+YeYBk0ej 3nLKjfyP3Kb/iOGqJl3gPknxjfJnFU2xVth4XneVZiK37soUv+CAOUiqAV+xZ4VFj29f hZsA==
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=MqzBDHWP8aRQEnSW6FJxPYmJCxZOyPa7lgY6F8gpQzs=; b=mDmGyFysvZX6DThZe3Nnh0Hi2Lmuz3T/dYHRfY3IqhcpTX5+wnJwoaHThL4q1wWmEE i9Feb97HTsUwQDz/kxQE0/j5wKBrCE2c/UJXaczItitSzhEsqsbFJ+797P/pyl+DnwLj bvd7OcL6l45PiCdhBikq7r+b+mc2OxrVaAAvkR2rLUNIYrXo+Q8z5ktcpF1nruzaAo1x b40W6afhtD9kSVSKLuYIJ0BP/cF7/rcgZeFFWQOZQVqLAk1KTlZaeamEn6QRaI+DKnc0 bbAvLduGLpuv3iOCc7Bcq4GSWgoTTkjxiURZuu5O3D5Paym5TvqjBj1hKyf8AF56T3ud 7EDQ==
X-Gm-Message-State: AOAM530wbJ+3eyMcwigfmBOVZDoH9WOEj+BIpsF+S1o9uBx3QgEQCU+3 H74L4poJ6yDul+E3ueSJHzSe1PhEDAG1B167bumPqXOu
X-Google-Smtp-Source: ABdhPJxLQctSj9w2GejXytzItIR4OJ1aU3U7ogVAOWYh2Dq4k4ggISC00rXAbowaOW8hXzPkuQivsETqfNCsFJbOQ6k=
X-Received: by 2002:a1c:46c3:: with SMTP id t186mr4843440wma.36.1591119311907; Tue, 02 Jun 2020 10:35:11 -0700 (PDT)
MIME-Version: 1.0
References: <DM5PR0601MB367115AD49513EAF3953716CF68B0@DM5PR0601MB3671.namprd06.prod.outlook.com>
In-Reply-To: <DM5PR0601MB367115AD49513EAF3953716CF68B0@DM5PR0601MB3671.namprd06.prod.outlook.com>
From: Dotzero <dotzero@gmail.com>
Date: Tue, 02 Jun 2020 13:35:01 -0400
Message-ID: <CAJ4XoYcDhiap3fMfCjUbjERDK+DH=Au+43Ycu_YR4dPRQmNKaA@mail.gmail.com>
To: Jesse Thompson <jesse.thompson=40wisc.edu@dmarc.ietf.org>
Cc: "dmarc@ietf.org" <dmarc@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000061b92905a71d5517"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/IFRVor2-qbYKNYEG9UtUkWsEe9o>
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:35:15 -0000

On Tue, Jun 2, 2020 at 12:44 PM Jesse Thompson <jesse.thompson=
40wisc.edu@dmarc.ietf.org> 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.
>
> [1]
> The "From:" field specifies the author(s) of the message,
>    that is, the mailbox(es) of the person(s) or system(s) responsible
>    for the writing of the message.  The "Sender:" field specifies the
>    mailbox of the agent responsible for the actual transmission of the
>    message.
>
> [2]
> signature verification failure does not force rejection of the message;
> "
>

We went through this with SenderID and it's use of Sender in PRA. Back in
the day I upset the folks at Microsoft responsible for evangelizing
SenderID by sending emails to them using their name an email in the From
field and myself in the Sender field. My emails would consistently get a
neutral rating under SenderID because of how PRA worked.

As part of the original DMARC team, the goal was to make clear whether the
email was authorized by the domain being used, hence the reliance on SPF
and DKIM. These are clearly under the domain owner/administrator's control
to the extent they choose to exercise that control. There was much
discussion in the community at the time to use thei= field to enable more
granular signing. it never gained traction. Because the intent was to
protect end users from fake emails purporting to be from (primarily)
commercial domains such as financial institutions, greeting card companies,
etc., the Sender field was not a significant issue. Also, when the Sender
is in the same domain as the From, there is no DMARC issue.

Michael Hammer

If you really want to enable someone to send on your behalf then a) give
them direct access to send from your account; b) give them your private
DKIM signing key (which allows them to sign for any account in that domain
or c) delegate a subdomain to them so they can generate their own SPF or
DKIM records.