Re: [Bimi] MUA Evaluation of BIMI

Dave Crocker <dhc@dcrocker.net> Tue, 15 March 2022 16:36 UTC

Return-Path: <dhc@dcrocker.net>
X-Original-To: bimi@ietfa.amsl.com
Delivered-To: bimi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F2A83A14E5 for <bimi@ietfa.amsl.com>; Tue, 15 Mar 2022 09:36:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.11
X-Spam-Level:
X-Spam-Status: No, score=-2.11 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, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=dcrocker.net
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 W9er1NhNTIuG for <bimi@ietfa.amsl.com>; Tue, 15 Mar 2022 09:36:32 -0700 (PDT)
Received: from bongo.dogwood.relay.mailchannels.net (bongo.dogwood.relay.mailchannels.net [23.83.211.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF1E83A13AD for <bimi@ietf.org>; Tue, 15 Mar 2022 09:36:25 -0700 (PDT)
Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 09998621EAD; Tue, 15 Mar 2022 16:36:23 +0000 (UTC)
Received: from gcp-us-central1-a-smtpout1.hostinger.io (unknown [127.0.0.6]) (Authenticated sender: hostingeremail) by relay.mailchannels.net (Postfix) with ESMTPA id 3BE82621D22; Tue, 15 Mar 2022 16:36:10 +0000 (UTC)
ARC-Seal: i=1; s=arc-2022; d=mailchannels.net; t=1647362171; a=rsa-sha256; cv=none; b=Ys5OxVTURu4lDr/qW1mw27ghgijqw7bhE+WeBaUgbm0q1UoWX3L8W50r5FDIy5ubK349Qy XdnhiqpLIbuZUAMp/kPX4JsVg4pHllVG6agdTLJKNy3uertXVcKzK2R7+HIHoq9xfYv+N9 y15Ko8U4rzpgjbM7VacTVbThn2gqO9OroHh2d/u/tZF20mxn6bRikT5QVgicxlTIIT9tBU jjelB4Xc+mvDnmW2duemZTlkT9qwiiVvmk2j8rUw4Xb7SUrhwLmHZ/xJIDMZFacd9UxuCP Qe9ZSpZ48Nky+gLadyY3qBjEjsbfjBV7VeW72wHK3+CMSEDUbPrd8a+Ujx0izA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=mailchannels.net; s=arc-2022; t=1647362171; h=from:from:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=e4ei/arJ5nKBFg+YhUP7cB+3avly542OsjvKq7Tx2pM=; b=Xgfe3k/JDCJGeHths2Q/Tn8cJUyZ3tSrKglcLE3AeeYW1olH2YpYxfAScJsluE6ZfGcSsK 0r+DQoOYWRta2fhpCwsoEvTpHIw7863Al+VhFK6x3UtyOYqptzjX3TcE2mN90ZI2eO/825 cur2vw5DVqyCAV8OUsqdc2T+aeAsNRtw+bY7t5IJUuDVMrbH2ZRB8rJn4Yz+uaT+1dT3or amnC7q9FPClCrQhRFvfadqH+iLtSPwTfiDU64sdOcJD12cEBmxw93zSNAtcwXCqoxivQPS +oMFseo2DLFnFtmSHbfmP9bFdvpHsMACvv4yMEWI2Zw1YkgQj30JRI4yzrOU3w==
ARC-Authentication-Results: i=1; rspamd-c9cb649d9-5zc67; auth=pass smtp.auth=hostingeremail smtp.mailfrom=dhc@dcrocker.net
Received: from gcp-us-central1-a-smtpout1.hostinger.io (gcp-us-central1-a-smtpout1.hostinger.io [35.184.15.197]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256) by 100.109.126.219 (trex/6.5.3); Tue, 15 Mar 2022 16:36:22 +0000
Received: from [192.168.0.112] (c-73-170-122-71.hsd1.ca.comcast.net [73.170.122.71]) (Authenticated sender: dhc@dcrocker.net) by smtp.hostinger.com (smtp.hostinger.com) with ESMTPSA id 4KHzYf1P5Yz2bklY; Tue, 15 Mar 2022 16:36:05 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=hostingermail-a; t=1647362169; bh=CdiGltzGLOnFUAWnPyns8rS9DQa7bqPCLCF2Odl9mNE=; h=Date:Reply-To:Subject:To:Cc:References:From:In-Reply-To; b=BU//Ouomd4/8r6AdELfyOSicOEYGAKJpyx3IJwzcPt90rgCUHzeGCA82m3sYOPiDX C6/+LJxtYq0mL0elYnnWTiEJII9ewNvy8bI1Mrz/unjmX/2JxPNYAgkYHZXBY49bTw GAYlRpPtL9yCC7WWEjaSUFnIphynYoO2ElMsi2g+CcZ052KHquEXyrFvUx8MErnqmF 9Pa7pm1VPa3ft8RmL/4kV6uS66xWLJoDl97B57b3H+lnlLxGO2lQ0NhTbWpU5D2h0L KL2fjigbGDy+rIMMaC7wNM9AGYO0aQKT4VexD1yEl4zJFfQ2d6f2z9tit2cGL5GpZU 2+J5zj4A2CCow==
Message-ID: <a9fc90ba-7015-cf52-e433-6bf80ca26b0a@dcrocker.net>
Date: Tue, 15 Mar 2022 09:36:04 -0700
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0
Reply-To: dcrocker@bbiw.net
Content-Language: en-US
To: Ken O'Driscoll <ken=40wemonitoremail.com@dmarc.ietf.org>, Trent Adams <tadams@proofpoint.com>, "Brotman, Alex" <Alex_Brotman=40comcast.com@dmarc.ietf.org>
Cc: "bimi@ietf.org" <bimi@ietf.org>
References: <7639D8E5-B8CA-48E6-B6F3-63BA091C3AC5@contoso.com> <VI1PR01MB7053B6AF625A5FFB2222F795C70F9@VI1PR01MB7053.eurprd01.prod.exchangelabs.com> <MN2PR11MB4351276056888F77815E220EF70F9@MN2PR11MB4351.namprd11.prod.outlook.com> <CB922168-3B56-488E-90DD-2591B064F9FF@proofpoint.com> <VI1PR01MB70533C10733D41443FD2A801C7109@VI1PR01MB7053.eurprd01.prod.exchangelabs.com>
From: Dave Crocker <dhc@dcrocker.net>
Organization: Brandenburg InternetWorking
In-Reply-To: <VI1PR01MB70533C10733D41443FD2A801C7109@VI1PR01MB7053.eurprd01.prod.exchangelabs.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/bimi/wDgW9E1v52-Go4A49f7UnV5IwXw>
Subject: Re: [Bimi] MUA Evaluation of BIMI
X-BeenThere: bimi@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Brand Indicators for Message Identification <bimi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/bimi>, <mailto:bimi-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/bimi/>
List-Post: <mailto:bimi@ietf.org>
List-Help: <mailto:bimi-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/bimi>, <mailto:bimi-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 15 Mar 2022 16:36:46 -0000

On 3/15/2022 9:28 AM, Ken O'Driscoll wrote:
> I don’t think there should be any recommendations that an MUA carries 
> out any independent validation or “double-checking” etc. It’s the wrong 
> place for the operation. If the upstream MTA is lying then all bets are 
> off anyway.


DKIM can work fine in an MUA-based validation.  Obviously there is 
nothing wrong with doing validation at the MTA/MDA level, but the 
architecture is, really, an end-to-end design, which means supportable 
in the recipient's MUA.  A DMARC that relies on DKIM rather than SPF 
also does.

So, not, it is not (necessarily) the wrong place for the operation.

As for the receiving MTA lying, turn the issue around:  how can the MUA 
know that the field came from that specific, well-behaved, thoroughly 
compliant MDA or MTA.

Broadly, how is the chain of trust established sufficiently for the MUA 
to know that the A-R header field is to be trusted?

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net