Re: [Bimi] Proposal to Clarify Role of MUA in BIMI Evaluation

Richard Clayton <richard@highwayman.com> Wed, 20 July 2022 01:32 UTC

Return-Path: <richard@highwayman.com>
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 1E4EDC13194D for <bimi@ietfa.amsl.com>; Tue, 19 Jul 2022 18:32:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.106
X-Spam-Level:
X-Spam-Status: No, score=-2.106 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, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=highwayman.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gkd8PkQ4-luY for <bimi@ietfa.amsl.com>; Tue, 19 Jul 2022 18:32:08 -0700 (PDT)
Received: from mail.highwayman.com (mail.highwayman.com [82.69.6.249]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8AFBCC131947 for <bimi@ietf.org>; Tue, 19 Jul 2022 18:32:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=highwayman.com; s=rnc1; h=Content-Transfer-Encoding:Content-Type: MIME-Version:In-Reply-To:References:Subject:From:To:Date:Message-ID:Sender: Reply-To:Cc:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=tBqttpf9rXWU8Axil9Az9N9J4KRl/Zqqs1fdNKP87OI=; t=1658280727; x=1659144727; b=uQ9DucsSBmCXJEbfoGg03StYDkshRSPrDC8Og7mMXiFBhEVt9x9CBfTKMKRlPQE9qNtxD5LzduE HBIv0l/+zAc2ZBhtXNGeLoH601RlMCHrFs0JQWCXKi9hgrWVNSMKnYPTFxhmdVwukCEgFbDNpPbPF 5oLBdOJVzmzpB+ACvWTvQYYcPXGUKwpd5U6ic/59e+I+LcbToEeRjvpJcuP8jMNi7CRZ1HOFskand GbWQTTb9Dxm8iOE6wgarweztI6IsNz4OTLWmbxlYctGo5seDLaIpCgE4mGDPqfCPGJCu+wDEq9lTy etsTcUdNUCTxqje2duefJMeELzyBmDD+E27g==;
Received: from localhost ([127.0.0.1]:46554 helo=happyday.al.cl.cam.ac.uk) by mail.highwayman.com with esmtp (Exim 4.95) (envelope-from <richard@highwayman.com>) id 1oDyZI-000ICY-UW for bimi@ietf.org; Wed, 20 Jul 2022 01:32:04 +0000
Message-ID: <qnuJf0TDr11iFAcB@highwayman.com>
Date: Wed, 20 Jul 2022 02:30:43 +0100
To: "bimi@ietf.org" <bimi@ietf.org>
From: Richard Clayton <richard@highwayman.com>
References: <DE61AC51-4BC3-44FF-862D-7D8ADFB3BC29@proofpoint.com> <20CBD506-7E50-4161-ADE6-64614630B1B2@proofpoint.com> <CAHej_8kridbc322MDRpxfgd+8Y2yNacxTAtvr+HF=+wevdRQhw@mail.gmail.com> <VI1PR01MB70538965904FD08A49F75C37C78C9@VI1PR01MB7053.eurprd01.prod.exchangelabs.com> <11A2B052-A26C-4A9C-9D88-72B594DA1C59@proofpoint.com> <VI1PR01MB70537BA29DA1F456B858C17FC78C9@VI1PR01MB7053.eurprd01.prod.exchangelabs.com> <6993E8B6-11A0-4AF3-A94E-044F880E56BC@proofpoint.com> <CAHej_8kjwtGE4rDrXfTpgThOD-jh7t0GK9EUnVjVZT_OJzzsvg@mail.gmail.com> <VI1PR01MB705353E36328899609DE2471C78C9@VI1PR01MB7053.eurprd01.prod.exchangelabs.com> <12a85dfe-664f-d757-0fa2-81f17c8088c2@dcrocker.net> <4e9ab94e-8675-df70-3e4b-00edcedb266e@dcrocker.net> <5DE65D46-853F-4F61-ADA7-20CB5E7E6840@kitterman.com> <7f030278-3f9b-c8ea-f9eb-644f006cded9@dcrocker.net> <CC11EF68-1E27-41CD-AE2D-AC26DA261EAD@kitterman.com> <CAHej_8mNCTw0LpnWTBCpqZJhHQcDgrsC4truK1dD_-HbyVgsWA@mail.gmail.com> <DM8PR14MB5237459AC795AE826FDDA198838F9@DM8PR14MB5237.namprd14.prod.outlook.com>
In-Reply-To: <DM8PR14MB5237459AC795AE826FDDA198838F9@DM8PR14MB5237.namprd14.prod.outlook.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
X-Mailer: Turnpike Integrated Version 5.03 M <n57$+zkv77$esOKLg+Y+dOq+FD>
Archived-At: <https://mailarchive.ietf.org/arch/msg/bimi/Zs2vufOTvE9myA5RPMKMcTEghg0>
Subject: Re: [Bimi] Proposal to Clarify Role of MUA in BIMI Evaluation
X-BeenThere: bimi@ietf.org
X-Mailman-Version: 2.1.39
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: Wed, 20 Jul 2022 01:32:13 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

In message <DM8PR14MB5237459AC795AE826FDDA198838F9@DM8PR14MB5237.namprd1
4.prod.outlook.com>, Tim Hollebeek <tim.hollebeek=40digicert.com@dmarc.i
etf.org> writes

>    I’m a bit concerned about the discussion of attempting to perform 
>    the checks at any other time, and I’m even more concerned about 
>    what seems to be assertions that it’s ok if the quality of the 
>    checks “degrades over time” as if this were a natural or 
>    unavoidable state.  I think everything possible should be done to 
>    avoid that outcome.

there appears to be an assumption in some of the discussion that
although all sorts of other information might degrade over time (or be
hard for an MUA to establish post hoc) that the image itself is still
magically available for fetching ...

Long ago I asked why the design was not a souped up version of X-Head
where the message and how to display it was entirely self-contained and
all that people who handled the message had to do was to assess whether
or not display was warranted. It does seem that might be somewhat
simpler to document (and implement).

>    Over in LAMPS, we’re spending a lot of time dealing with the 
>    fallout from similar issues being inadequately addressed in the 
>    past with secure email, causing exactly the phenomenon described 
>    here, where over time things just degrade.  It’s very confusing to 
>    end users, and negatively impacts confidence in the entire system 
>    when things change with time, seemingly for no reason.

there is related experience in the PGP world where messages which once
were valid become invalid over time and disappointing the user by
failing to display them does not seem attractive

- -- 
richard                                                   Richard Clayton

Those who would give up essential Liberty, to purchase a little temporary 
Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755

-----BEGIN PGP SIGNATURE-----
Version: PGPsdk version 1.7.1

iQA/AwUBYtdaw92nQQHFxEViEQLcYgCdFWxvKtT5OE2fG1PRUv65bG0S/HwAn2lC
jdt59DCQmHOpaQf+Ujfc60YQ
=Z7VD
-----END PGP SIGNATURE-----