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> Thu, 04 June 2020 14:57 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 82DBE3A0833 for <dmarc@ietfa.amsl.com>; Thu, 4 Jun 2020 07:57:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_EF=-0.1, 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=wdCkAM0O; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=1OINStxM
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 sb0C_rsLRQ_t for <dmarc@ietfa.amsl.com>; Thu, 4 Jun 2020 07:57:13 -0700 (PDT)
Received: from wout1-smtp.messagingengine.com (wout1-smtp.messagingengine.com [64.147.123.24]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 102933A081F for <dmarc@ietf.org>; Thu, 4 Jun 2020 07:57:13 -0700 (PDT)
Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.west.internal (Postfix) with ESMTP id 2F519964; Thu, 4 Jun 2020 10:57:12 -0400 (EDT)
Received: from imap6 ([10.202.2.56]) by compute2.internal (MEProxy); Thu, 04 Jun 2020 10:57:12 -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 :cc:subject:content-type:content-transfer-encoding; s=fm3; bh=6a ZCEXe523a2nkzFXNnJ4a83rYUYfyURRno9x9sm1Rk=; b=wdCkAM0ONFA5seq/hB G7POeRWcSRd5n+K7SoMBS93+b13mCJ/L9+e3gCPeYXZE6t7hmuI2doAPlUqwfRu8 7HCh5Zfxf14Cw4zQkPCJVjTRPpjGZmGtMSDymi7vQiZgIPcrxzJXbuCCZeqd5swz ZGrfhpX70H7Bj0u/LyFpJSIUHG2viaU0JgSXUcydP8mSUt/VfPfJVJp7fYMnBbY6 MYLQDFB7qvBgTmQk+Ao8C2WQt/vyixPS/WvycocRIEvxD15SmKpeP3VQ8Y1ckPZr vYQ6FAJ0uhgHpQibXiBnM2LARxfmyre+6WLK0lUduufN0u5W1KA6CR5lcLMUK6he ryXA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding: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=fm2; bh=6aZCEXe523a2nkzFXNnJ4a83rYUYfyURRno9x9sm1 Rk=; b=1OINStxMvNV/pD9l9YNd4/c7pkx/B4fEc0eAqOa5EAaFnGFqAlz9G1y8k Muf0Esn+5+OQ+tfnklofjpoV/dDb/LlSydTHZw+fr2dndD/RltK2dcjL7C6hWERK BrU0FpTw5iK+d1GmyuTlYs7v0QXCapJ2K0X0iTTmx7pWfldS33wuSH4WYCaoKhh6 NxqJom6erxZ4hcHtVLOMPKPizXDMAE6WvaWoEt5RFCzCV/dqT9dgCP1jncQVz4EH Nbd16mmSdtJ6yp8+/0sBVZtVDYTDqkX3UnTL+2lB0x2SHDsOOTlguWwDwFWT20+V 0+oJT46WychK6HtXe32eMyuNx2PsQ==
X-ME-Sender: <xms:xwvZXt_SV6dOMjNDncKC1K5nC3W-D5jJIsArpsyJAzi1lznFzyzBvA>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrudeguddgjeekucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgfgsehtqhertderreejnecuhfhrohhmpedfufht rghnucfmrghlihhstghhfdcuoehsthgrnhesghhlhihphhgvihhnrdhmrghilhhfohhrtg gvrdhnvghtqeenucggtffrrghtthgvrhhnpedvjeehjedvvedtffeugfetieevvdfhgffg leffheetteekvdelueegieffuddtueenucevlhhushhtvghrufhiiigvpedtnecurfgrrh grmhepmhgrihhlfhhrohhmpehsthgrnhesghhlhihphhgvihhnrdhmrghilhhfohhrtggv rdhnvght
X-ME-Proxy: <xmx:xwvZXhs_Yze845ANkgAnYtzkZz4cFLVqPTy-XkSV7bEyOVCZdHeMag> <xmx:xwvZXrB4OE4uhZAGYNBayRf2qtObK5VeQgH7z1th5MkO9Fkc7dzhmw> <xmx:xwvZXhfvnDGUrSnEaLIlTrgn9AVQob4sRM1LI5H9pQOnQEVhi4xjNw> <xmx:xwvZXlYaqBvReUzHT4RBpPG2FSOSCB0g8P_IXHD_tjzAhtIgF46kFg>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 260C71400A1; Thu, 4 Jun 2020 10:57:11 -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: <652580c1-5f8b-4d11-af25-d968b277c2b5@www.fastmail.com>
In-Reply-To: <b23c91d7-d1b6-6a90-6f59-57178b0fa826@tana.it>
References: <DM5PR0601MB367115AD49513EAF3953716CF68B0@DM5PR0601MB3671.namprd06.prod.outlook.com> <18441e8d-cf87-053e-4957-7b9d6ea9690c@gmail.com> <ff98e267-8e7b-2015-cc1b-7061d04097d8@tana.it> <71b7426b-4619-fd50-4038-3418f3181b1d@gmail.com> <2d1d4b31-ad19-db95-b32d-f89c914195a5@tana.it> <1f04f4fd-5c92-b61d-3ca1-e6ea954e33f7@gmail.com> <b23c91d7-d1b6-6a90-6f59-57178b0fa826@tana.it>
Date: Thu, 04 Jun 2020 10:56:18 -0400
From: Stan Kalisch <stan@glyphein.mailforce.net>
To: Alessandro Vesely <vesely@tana.it>, Dave Crocker <dcrocker@gmail.com>
Cc: dmarc@ietf.org
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/tNNJUDHraHKDj17Iun6DZUHaH8I>
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: Thu, 04 Jun 2020 14:57:15 -0000

On Wed, Jun 3, 2020, at 2:30 PM, Alessandro Vesely wrote:
> On Wed 03/Jun/2020 19:27:52 +0200 Dave Crocker wrote:
> > On 6/3/2020 10:20 AM, Alessandro Vesely wrote:
> >> On Wed 03/Jun/2020 18:43:16 +0200 Dave Crocker wrote:
> >>> On 6/3/2020 9:38 AM, Alessandro Vesely wrote:
> >>>> MUAs should be discouraged from displaying or using Author:, unless
> >>>> (verifiably) signed by a trusted domain or otherwise configured by the user.
> >>> Why?
> >> That avoids the dreaded back-to-square-one path that Brandon conjectured.  It
> >> prevents attacks based on this field, while maintaining the DMARC paradigm.
> > 
> > The barrier you specified sounds reasonable.  But it isn't.
> > 
> > Any signature put in place when the Author: field is created is likely broken
> > by the time it gets to the recipient.  That's the entire problem that
> > necessitates rewriting the From: field.
> 
> 
> That depends on who creates the Author: field.  I'd imagine it can be created
> on rewriting From:.  If it exists already at that time, one can still check (by
> ARC?) if it was signed, and, in case, sign it in turn.

I, too, was wondering whether ARC was really the only practical way to attempt this, assuming you don't think it deviates enough from ARC's purpose.


Thanks,
Stan