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

Todd Herr <todd.herr@valimail.com> Wed, 20 July 2022 12:41 UTC

Return-Path: <todd.herr@valimail.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 15699C16ECCB for <bimi@ietfa.amsl.com>; Wed, 20 Jul 2022 05:41:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.104
X-Spam-Level:
X-Spam-Status: No, score=-2.104 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, 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=valimail.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 YnCAM2_GDJkz for <bimi@ietfa.amsl.com>; Wed, 20 Jul 2022 05:41:49 -0700 (PDT)
Received: from mail-yw1-x1132.google.com (mail-yw1-x1132.google.com [IPv6:2607:f8b0:4864:20::1132]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 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 B775CC16ECA1 for <bimi@ietf.org>; Wed, 20 Jul 2022 05:41:49 -0700 (PDT)
Received: by mail-yw1-x1132.google.com with SMTP id 00721157ae682-2ef5380669cso172106607b3.9 for <bimi@ietf.org>; Wed, 20 Jul 2022 05:41:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=173hrWdK5HLrrrwDq92GHTHaFlALdVfbmE/NFDtxknA=; b=aPSVHPJSwLIBC5sJZOHealTjnE8AYMPQ5p17uxmgOnRfL7A4+5XomcuGi8kRv17X+d KExM7tX6I4h1iFS6BOGHNhDFY6lMZCE16cCF5OfhHbkLIvPP3R9sSgA+S03vxyf/gwgq D5q3DoZhc1HGRjpnvSwnRtIfWq3CevWRZ7fjfij7/rtxQzUgqUKV9M56zGPzuK9AJI3c GZvr0wexTm6kMT7hV+qn+DXX7zk+wQyXu7Wg2B9tUtp6eLCpDhRkX+pLvtB1oZwX9gfu NJoMdfAHw5d0JijpkD7gCVFzv1QF4KbpBczoxYhG4sRJXWnOD8biK7zeeiJZwKA5Cx2L qhOg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=173hrWdK5HLrrrwDq92GHTHaFlALdVfbmE/NFDtxknA=; b=x+JpVE3lKgPn4OE4Tm3oYFvU8LP4vP47saqdVN9FoGRHk/nvwTeffki3+bk7bXHUif PlaYwAoXR0V9l0fqAdWY5+cylkiAMX1n9cK6un4/xV9iXXxhOAhz+vBMYrLmbEc+QS+s p3h2ZjvRpYwdpZbaMun429PutO1AAP1eW+9OAuoSUUemgG9HwEywBBSalJR375YFdObt POy6JV6UagTF3WE9fGdI/zyqbzFo9UUIH3Hk1q1QA2Czt/ikz/EIHPixVdl6cKHfqlgx lAfK7fy+0GyH2XaVevK+4sXesBvU26WaodfHbUwjPY4aTvkWOTyLfYB1lsR6Hlc3uvct gOsA==
X-Gm-Message-State: AJIora/0TsoQMLsGwxHP0jqQ0xhtR6T1wnBYTD81HZxmVedJBcBaFg5S CDekaMegmH1Cx0gsLj9f8Dt+7IYNCS8kKCOxnTnVL/MkJ1Yg6A==
X-Google-Smtp-Source: AGRyM1sP/i6GneIU+FLRe2Ycq+/RYLRKKpjv2oM1kR7dOsXKNuI8B7vyLcFqBDQdY57km8dxM54+O9lqHtcx7wNbnD8=
X-Received: by 2002:a81:5a06:0:b0:31d:a775:7350 with SMTP id o6-20020a815a06000000b0031da7757350mr41649998ywb.130.1658320907977; Wed, 20 Jul 2022 05:41:47 -0700 (PDT)
MIME-Version: 1.0
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> <qnuJf0TDr11iFAcB@highwayman.com>
In-Reply-To: <qnuJf0TDr11iFAcB@highwayman.com>
From: Todd Herr <todd.herr@valimail.com>
Date: Wed, 20 Jul 2022 08:41:32 -0400
Message-ID: <CAHej_8kySKk4_F3eVDRQU4ABjs3JUg4Z9UipTwGJE2nSJQ5SJA@mail.gmail.com>
To: "bimi@ietf.org" <bimi@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000a4d97a05e43becc5"
Archived-At: <https://mailarchive.ietf.org/arch/msg/bimi/7taxHqNUU3-ZE86B9bQfMHXDAzI>
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 12:41:54 -0000

On Tue, Jul 19, 2022 at 9:32 PM Richard Clayton <richard@highwayman.com>
wrote:

> -----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 ...
>
>
I'm not clear on what you mean by the phrase "magically available for
fetching" here.

The current draft of the BIMI specification describes a "BIMI Assertion
Record" (
https://datatracker.ietf.org/doc/html/draft-brand-indicators-for-message-identification#section-4.2)
as a relatively straightforward DNS TXT record, one making use of a
tag-value syntax, not unlike a DMARC policy record.

One of the two possible tags in the BIMI Assertion record is "l="
(lowercase ell), defined as:

   location (URI; REQUIRED).  The value of this tag is either empty
   indicating declination to publish, or a single URI representing the
   location of a Brand Indicator file.  The only supported transport is
   HTTPS.


The "Brand Indicator file" is the SVG file containing the image to be shown
if the message meets requirements for doing so.

What's magic about that?

-- 

*Todd Herr * | Technical Director, Standards and Ecosystem
*e:* todd.herr@valimail.com
*m:* 703.220.4153

This email and all data transmitted with it contains confidential and/or
proprietary information intended solely for the use of individual(s)
authorized to receive it. If you are not an intended and authorized
recipient you are hereby notified of any use, disclosure, copying or
distribution of the information included in this transmission is prohibited
and may be unlawful. Please immediately notify the sender by replying to
this email and then delete it from your system.