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

"Murray S. Kucherawy" <superuser@gmail.com> Mon, 08 June 2020 03:04 UTC

Return-Path: <superuser@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 94CB03A097A for <dmarc@ietfa.amsl.com>; Sun, 7 Jun 2020 20:04:31 -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 TYMQ8QtJUCDg for <dmarc@ietfa.amsl.com>; Sun, 7 Jun 2020 20:04:29 -0700 (PDT)
Received: from mail-vk1-xa43.google.com (mail-vk1-xa43.google.com [IPv6:2607:f8b0:4864:20::a43]) (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 706E83A0977 for <dmarc@ietf.org>; Sun, 7 Jun 2020 20:04:29 -0700 (PDT)
Received: by mail-vk1-xa43.google.com with SMTP id t23so3608246vkt.5 for <dmarc@ietf.org>; Sun, 07 Jun 2020 20:04:29 -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=DkxNWiVPG22Q9qcSU57Su8ggoXOiTHHcLmk2szUUsaQ=; b=sV8laat+2a2gByOby7gbcYIYoi/6aZrUXsGUrk2kDRS2Tlp2BgFYPawHGYoFGN5cVK romFrV49oP+158K8jZqIiH3u0lz1SDUWq9UO+Nvw6+AIHiTJwMKEjxMZWPZTOZmdEZZu HWcL056wA+IBPtWCg157CRuqNzexmlBzIIxYWtFzPVH7743L3jrBHh9zMIBCTlS4kXTy YBe+yjicV76UW1MuMX3wB/5JQlbVSZNCuVBu8dO9Cl2vP38FgmV+WqAJB/Lb3Vj0LGI6 Kpj0evcuosrWInoCJAlM9nzE4SKnM7xlenr+CtxS3B5n/BZKwGUnKyi9/otqGOQ/lM55 wunA==
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=DkxNWiVPG22Q9qcSU57Su8ggoXOiTHHcLmk2szUUsaQ=; b=lf4rj5movCh6t0y03OKeFRAvnZpcr9929FLOBqtPbLJVmn+Gw9QdWHru06ypqCPlQs kOFIHchfQQq+YAwgt1vw/FdD/pZdlKkexMtFeR0/oYXAA1Kr6gZG4/02iJH3+1orDtYR KUnZ2HVO54xlmW3GkvyagrTqPc573Nn+JN6VuWbxmkV43EXuXwxThGvZaY5suIENDTKt KJpR1FXSdnYF0O6KTNX6YoLar3OnY5UzTQxx1r7gWpJ33PJSnX87JT/p0Lmp4aACvH71 xmPDxUGjU56OxE3FsnixL8fjHkUKSBhlYsD+J1aIqSDWQMlU/KIok3uXOWicPGY+4lre YbpQ==
X-Gm-Message-State: AOAM530S+YUw/dJlCdqLf9cOqiqnhq/9TbEQ3/xWkc8vqLUMQCMT2t5k dLPyZzXwlknQfVYYWrwFMsLwBhPVI5Ab0+uCpIAYTw==
X-Google-Smtp-Source: ABdhPJwnBuRBWGZ2ZOO/Qs69DhxkMMfQil+ISVw2MM3kkLwPkgPhnO+L73nvLn2H4uPjyl2/E00VekBo5AdLNckOwGQ=
X-Received: by 2002:ac5:ccf0:: with SMTP id k16mr13891791vkn.95.1591585467078; Sun, 07 Jun 2020 20:04:27 -0700 (PDT)
MIME-Version: 1.0
References: <DM5PR0601MB367115AD49513EAF3953716CF68B0@DM5PR0601MB3671.namprd06.prod.outlook.com> <11640715.3lbasgNmsr@sk-desktop> <25420528-d356-0273-ceb3-c44a3c94bc91@gmail.com> <3138524.EPDo7oxCqE@sk-desktop> <4620e21f-32c5-7735-9faf-a5b045f84c0d@bluepopcorn.net> <ac0f684a-4c00-0564-8cf9-5b955e037c87@tana.it> <14fe18acad53467a8027e680dfc1067e@bayviewphysicians.com>
In-Reply-To: <14fe18acad53467a8027e680dfc1067e@bayviewphysicians.com>
From: "Murray S. Kucherawy" <superuser@gmail.com>
Date: Sun, 07 Jun 2020 20:04:14 -0700
Message-ID: <CAL0qLwbkX0tVneKebQAeqNJ99wS6KcZdXx1+D0nBjsHiTFGaag@mail.gmail.com>
To: fosterd@bayviewphysicians.com
Cc: IETF DMARC WG <dmarc@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000651a9405a789def2"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/kBaceizTnak8Pa9iYnXg4Iwi2Jw>
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: Mon, 08 Jun 2020 03:04:32 -0000

On Sun, Jun 7, 2020 at 6:58 AM Douglas E. Foster <
fosterd@bayviewphysicians.com> wrote:

> 1) The original assertion, that DMARC creates a conflict with prior
> specifications, appears to be undefended and incorrect.   For From
> Addressing, It merely establishes some boundaries that the sender and the
> recipient choose to consider appropriate.    For DKIM, it creates a
> use-case for a technology that was initially defined without any use cases.
>    Consequently, I think this topic is ready for closure.
>

 I claim your assertions here are contradictory.  Specifically, by
establishing "some boundaries", it is creating a conflict with prior
specifications which established none, possibly intentionally.

3) Some of the discussion has been about how to prevent soclal engineering
> of the recipient user.  This is an important topic, but not directly
> related to the project.  IETF would do well to establish some
> recommendations about how MUAs should behave, so that trust data can be
> displayed to the user.   A typical user will have access to at least three
> different email clients: one on his cell phone, a product-specific web
> page, and a desktop product like Outlook or Thunderbird.    If I wanted an
> organization policy that controlled when Friendly Name was displayed or
> DMARC status was displayed, I would have to find and distribute plug-ins to
> all of these products.   As best as I have been able to tell, no such
> plug-ins even exist for Outlook and the other products do not accept
> extensions.   There is an opportunity here for valuable standardization.
>

The IETF has routinely punted, at least in the email space, on the idea of
prescribing or proscribing user interface behaviors because we are protocol
engineers, not human factors experts.  Are you claiming that's changed?

-MSK