IETF Logo Mail Archive

Re: [Bimi] BIMI & the MUA

Taavi Eomäe <taavi@zone.ee> Thu, 07 September 2023 08:15 UTC

Return-Path: <taavi@zone.ee>
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 5CCF9C14CE5E for <bimi@ietfa.amsl.com>; Thu, 7 Sep 2023 01:15:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.197
X-Spam-Level:
X-Spam-Status: No, score=-2.197 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.091, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=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=zone.ee
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 tB5KwYZ_9V6K for <bimi@ietfa.amsl.com>; Thu, 7 Sep 2023 01:15:37 -0700 (PDT)
Received: from MTA-244-116.TLL07.ZONEAS.EU (mta-244-116.tll07.zoneas.eu [85.234.244.116]) (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 917CCC14CEF9 for <bimi@ietf.org>; Thu, 7 Sep 2023 01:15:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zone.ee; q=dns/txt; s=zone; bh=QOtLeH+e3C9pyXzMPDLZdZ5cUc2MWZB1OHnltVaCvIs=; h=from:subject:date:message-id:to:mime-version:content-type:in-reply-to:references; b=zKa2YvD4UvDjK4dCvMYX9o40IxeBilX4okoJjMrbX7fFGy0DJEAVSrxeV93M7fOgVLdzq5kmg G8bkVXxq22UXEV8BkVgfGgqnflEnyo4+FBlKiSQ6FcGw84ebug1my4k3gaKhWN79+kkYh98tpcu zg3ON83miDwNxwNbRRiv2/zgtOlNM0U9hY7w8j7Srg8RrTY5puyD349mFB/i4fKDlQLYagH3qfo vSdHBlp3xLbiiFVuZyUC38/arLc9ot2WTmdGOzsvDr+pNpPrZJYIhEU1dSJY7evkMsDr7hLgHo5 Q/oWGvLsIgyX5wMWRdT5KYoqXpQM5N9cxgdXXwDFjoBQ==
Received: from [192.168.110.11] [217.146.66.6] (Authenticated sender: zmail526721[taavi@zone.ee]) by MTA-244-116.TLL07.ZONEAS.EU (ZoneMTA Forwarder) with ESMTPSA id 18a6eb5e2df000024c.001 for <bimi@ietf.org> (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Thu, 07 Sep 2023 08:15:28 +0000
Message-ID: <d15564bc-8fe8-c118-29e6-e18657c582af@zone.ee>
Date: Thu, 07 Sep 2023 11:15:27 +0300
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0
Content-Language: en-US
To: bimi@ietf.org
References: <MN2PR11MB43512B68983A21E6B546E0BDF7EAA@MN2PR11MB4351.namprd11.prod.outlook.com> <5a3abe26-cb49-5350-0abd-a106125fb087@zone.ee> <MN2PR11MB43518ED6E51BD484B3342518F7EEA@MN2PR11MB4351.namprd11.prod.outlook.com>
From: Taavi Eomäe <taavi@zone.ee>
Organization: Zone Media OÜ
In-Reply-To: <MN2PR11MB43518ED6E51BD484B3342518F7EEA@MN2PR11MB4351.namprd11.prod.outlook.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="------------ms040906090404090309000908"
Archived-At: <https://mailarchive.ietf.org/arch/msg/bimi/AZI6KZH_DDeAs6OjMuO2j7dco4c>
Subject: Re: [Bimi] BIMI & the MUA
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: Thu, 07 Sep 2023 08:15:41 -0000

Hi,

Are such mail systems (that don't add/replace A-R) really that big of a 
concern to necessitate this complexity? I imagine such systems introduce 
many other attack vectors anyways and it's impossible for a MUA to truly 
protect themselves against such an untrustworthy MTA. I'd imagine such 
MTAs would also not implement DMARC for example.

Though even in that case, a DKIM signature that covers the A-R header 
(plus some other restrictions) seems significantly less error-prone and 
complex than a brand-new header. In the end MUAs having to implement 
DKIM still seems like unnecessary complexity considering the current 
reasons why it's done.

I kind-of don't see why authorization would have to be revoked that way. 
What's the scenario where BIMI and its VMC is valid on reception but 
isn't afterwards? It should be clearly outlined what's the specific 
attack that would be thwarted.



Best Regards,
Taavi Eomäe
Zone Media OÜ

v2.23.0 | Report a Bug | By Email