IETF Logo Mail Archive

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

Stan Kalisch <stan@glyphein.mailforce.net> Sun, 07 June 2020 17:54 UTC

Return-Path: <stan@glyphein.mailforce.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 BB2E93A040F for <dmarc@ietfa.amsl.com>; Sun, 7 Jun 2020 10:54:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=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=mailforce.net header.b=y5OgwLEv; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=J0AEWzsf
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 7FpcxG3ThklX for <dmarc@ietfa.amsl.com>; Sun, 7 Jun 2020 10:54:26 -0700 (PDT)
Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 357953A0400 for <dmarc@ietf.org>; Sun, 7 Jun 2020 10:54:26 -0700 (PDT)
Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.west.internal (Postfix) with ESMTP id 61EAD458 for <dmarc@ietf.org>; Sun, 7 Jun 2020 13:54:25 -0400 (EDT)
Received: from imap6 ([10.202.2.56]) by compute2.internal (MEProxy); Sun, 07 Jun 2020 13:54:25 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mailforce.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm3; bh=tunoTnYrlMfmxyuqhEQ5a2Znk/6q9zW Q7ct7zGHxvB8=; b=y5OgwLEvUfNgLlHsb440hBmWsGV2LJe5TQBG2ZuUijyrE6X U1mK/c8HW6JZD3xhToPfh8D4CcmgIs4CNa/APuEz+P30+gZmISymXg6MoUckgnuI F6YWDpawQ5XXcdIaWPXXugAL3Kl5uF2zJmOwVRBdnjs9Ij/0BUhlZfPNks/W/jV/ TTwdU40ukEQbDtLLyouUtZ9PxTgkdFJYU3MXZCdb47lvLcOgp2UxPnFgpFLtYkid tTGIXeSjM7Pr3OyKO4q7Qv74gQS+JFCASNMvGMZHjMFQ4uRPLfL5CoM59uo46gyw gvsu/77ssJ4o96+33F2l8AILk3hQUvfFZ0CRVSQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=tunoTn YrlMfmxyuqhEQ5a2Znk/6q9zWQ7ct7zGHxvB8=; b=J0AEWzsfbEA3gIikFVlhhl Bwn+ZoB+cK8IZxaryKJO/PL7CWDTFwm6pK6s+XrJdtKVgi1lnd8Ts/6Dx2WNwEoA U3IhHsyiNWzwgCqsvbsnEBs3gO21b1hUYnoaTEviDDqbXo/v3XeJXfL2w4hvka3I XR6aE/BGRfyu3HoQCGRB2y3cXs0PE2IZdz2ziHDR5EKja03+fF/lHw7WbyXQs/90 9iXRKQsMw9LaLXxsh2jmv/be5zD890nzb+AhUCr6VmVVjDo4WGUPT+Kk0hsbmFE/ 11rfrlDzYdWcr6LQ4xKPmfEG/62REirUxps1H92+vBrnfH+0qS45o7kFs/iLIhOQ ==
X-ME-Sender: <xms:0CndXrnLmqzHWWTtVWqA9yl3V3xHlBGAeL-9oNJ_s3NnCEqmELodQw>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrudegledguddvudcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesrg dtreerreerjeenucfhrhhomhepfdfuthgrnhcumfgrlhhishgthhdfuceoshhtrghnsehg lhihphhhvghinhdrmhgrihhlfhhorhgtvgdrnhgvtheqnecuggftrfgrthhtvghrnhepie fgvddvffeikeeukeekueeiuedukeeltefhffffffduueeftdejkefggfduheegnecuvehl uhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepshhtrghnsehglh ihphhhvghinhdrmhgrihhlfhhorhgtvgdrnhgvth
X-ME-Proxy: <xmx:0CndXu0PcxWtff8YmK71CvNVR5EBPpFZ_TT5TQbUV1kg5VRDUd38Sw> <xmx:0CndXhoOKa5XSoMdtuJzV1GDVs8O3k_ydlzGLlbm_zWyqBSXeGD1Tw> <xmx:0CndXjnJAdtjPmWXrUHKxSQzLeGyPsTZzgqCEkqKdMHbQTJvldhSMg> <xmx:0SndXo0uw1TJZvqVPDp5vgghZ2WLWic7LaT3PZU3gjIyk-IzRqWrxA>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 9C8191400A1; Sun, 7 Jun 2020 13:54:24 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.3.0-dev0-519-g0f677ba-fm-20200601.001-g0f677ba6
Mime-Version: 1.0
Message-Id: <46e045ae-9691-4f5b-86bf-142c066458d8@www.fastmail.com>
In-Reply-To: <14fe18acad53467a8027e680dfc1067e@bayviewphysicians.com>
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>
Date: Sun, 07 Jun 2020 13:53:54 -0400
From: Stan Kalisch <stan@glyphein.mailforce.net>
To: dmarc@ietf.org
Content-Type: multipart/alternative; boundary="01c3bfda549e4be5a576178d67b84bc2"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/ePNBnIUUsLpkIkCLg462C2rKHXI>
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: Sun, 07 Jun 2020 17:54:28 -0000

On Sun, Jun 7, 2020, at 9:16 AM, Douglas E. Foster wrote:
> 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.

Assuming this can be practically done, I would rephrase this, "...[E]stablish how MUAs should display trust data to users."

Which is a question many have struggled to answer, given the history of users understandably wanting to pull their hair out over trust data and warnings.


Stan

v2.23.0 | Report a Bug | By Email