Return-Path: X-Original-To: bimi@mail2.ietf.org Delivered-To: bimi@mail2.ietf.org Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id DE083345DC95 for ; Thu, 12 Jun 2025 16:31:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at ietf.org X-Spam-Flag: NO X-Spam-Score: -2.798 X-Spam-Level: X-Spam-Status: No, score=-2.798 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_LOW=-0.7, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=marcbradshaw.net header.b="X3Lyke2k"; dkim=pass (2048-bit key) header.d=messagingengine.com header.b="aqmgoVRn" Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2JTil9z956Dm for ; Thu, 12 Jun 2025 16:31:51 -0700 (PDT) Received: from fhigh-a2-smtp.messagingengine.com (fhigh-a2-smtp.messagingengine.com [103.168.172.153]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id 0FCAA345DC85 for ; Thu, 12 Jun 2025 16:31:51 -0700 (PDT) Received: from phl-compute-11.internal (phl-compute-11.phl.internal [10.202.2.51]) by mailfhigh.phl.internal (Postfix) with ESMTP id EECB911401FB; Thu, 12 Jun 2025 19:31:50 -0400 (EDT) Received: from phl-imap-07 ([10.202.2.97]) by phl-compute-11.internal (MEProxy); Thu, 12 Jun 2025 19:31:50 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= marcbradshaw.net; h=cc:content-type:content-type:date:date:from :from:in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:subject:subject:to:to; s=fm3; t=1749771110; x= 1749857510; bh=5PuFP3EqoCTbZskgDQlbhcrECpLiotWxuLCElHeLP/U=; b=X 3Lyke2k5sCs5iThsig31CXt0Zp6yiHiSK75u7O+d+IUJPAWPrFWqwf+Ou2t/+4yq J2FxKisCL5ox3rT/C2fwKhwyTLndquCIewO2/a3303Fsdp4yzHE9lAI16wJvG0Hy 47oSIdfwg2/LpOZ/SxWeCHKRCL0BjYal9O7TDKU4UmuAc2fIuDZ9cHjgRrr28M0P coBUILqwSu7hJzRjafw5wQrsf2xZ2Buaiv0W3fWqh6z6wn69SE5mP/rHJGo0N7ne pDxsycb99WkQAa2JR4k5zn6hVOIJKXuW70rS83JLPCrBlnViZQAPCKSiq8Vnjsv8 PSIHSKOL3/W55AsL33ZdA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:subject:subject:to :to:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t= 1749771110; x=1749857510; bh=5PuFP3EqoCTbZskgDQlbhcrECpLiotWxuLC ElHeLP/U=; b=aqmgoVRnbJcU/c9MdPmAeq3rnwGsQNiEkWJI9a7ntuzxGhJwz1y M6BsOlXZNTrWb1mzXxL6QD0LfJgawpEPyE1300UDOqyL/j5BXVhLJzpWcir/YuM7 aAdeDuLgLLY6mgQHEkCQA9tAFjfCrfKp1d/m78EB10NOk8WquuEuRr7Wrr04zLCG 4m11v+LZE4KFl9JwaSf/wiA5WvnmjLiy9cvif0WqA+awMVx+2Qb5vUlzhaYuFkXP kiKBytM3cuixiyoHw1J5xxMrjwgploobjb/CWedT/uX8wtCZKLd66eJwECey1kpw HRByuWvSve95DyzORcxVlVY+1krTF5rLKvg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtddugdduieegtdcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpggftfghnshhusghstghrihgsvgdp uffrtefokffrpgfnqfghnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivg hnthhsucdlqddutddtmdenogfuuhhsphgvtghtkfhmghffohhmrghinhculdeftddmnecu jfgurhepofggfffhvffkjghfufgtsegrtderreertddtnecuhfhrohhmpedfofgrrhgtuc eurhgrughshhgrfidfuceomhgrrhgtsehmrghrtggsrhgrughshhgrfidrnhgvtheqnecu ggftrfgrthhtvghrnhephedugeeufeehkeeiieevtdetgeetffdvgeeghedvleevveefle ejffeuvddtkefgnecuffhomhgrihhnpehurhhluggvfhgvnhhsvgdrtghomhdpihgvthhf rdhorhhgpdhmrghrtggsrhgrughshhgrfidrnhgvthenucevlhhushhtvghrufhiiigvpe dtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmrghrtgesmhgrrhgtsghrrggushhhrgif rdhnvghtpdhnsggprhgtphhtthhopeefpdhmohguvgepshhmthhpohhuthdprhgtphhtth hopegrnhgurhgvfiesrghithgthhhishhonhdrmhgvrdhukhdprhgtphhtthhopegrlhgv gigpsghrohhtmhgrnhepgedttghomhgtrghsthdrtghomhesughmrghrtgdrihgvthhfrd horhhgpdhrtghpthhtohepsghimhhisehivghtfhdrohhrgh X-ME-Proxy: Feedback-ID: idcd04265:Fastmail Received: by mailuser.phl.internal (Postfix, from userid 501) id 544601EA0064; Thu, 12 Jun 2025 19:31:50 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface MIME-Version: 1.0 X-ThreadId: T474c3532fcdd1e31 Date: Fri, 13 Jun 2025 09:30:58 +1000 From: "Marc Bradshaw" To: "Brotman, Alex" , "Andrew C Aitchison" , "bimi@ietf.org" Message-Id: <2f956d8c-87d6-438c-9139-363f25c42bc3@betaapp.fastmail.com> In-Reply-To: References: <5cafd3c4-1f4d-01fa-89ec-ddddf555f8e5@aitchison.me.uk> Content-Type: multipart/alternative; boundary=536d779f780244f4ab17652642a390a3 Message-ID-Hash: QLOKXGSDNPIXWK72L2RG7LXSBHLQRDPJ X-Message-ID-Hash: QLOKXGSDNPIXWK72L2RG7LXSBHLQRDPJ X-MailFrom: marc@marcbradshaw.net X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header X-Mailman-Version: 3.3.9rc6 Precedence: list Subject: =?utf-8?q?=5BBimi=5D_Re=3A_BIMI_headers_that_an_MTA_must_delete?= List-Id: Brand Indicators for Message Identification Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --536d779f780244f4ab17652642a390a3 Content-Type: text/plain Content-Transfer-Encoding: 7bit I would not state that the AR header MUST be removed, this would depend on how the receiving system consumes them. I would expect there to be matching on the authserv id, and that inbound ARs with conflicting authserv IDs would be removed or renamed. This is all outside of the scope of BIMI. I would support stating that the BIMI-* headers MUST be removed or renamed on ingress. On Fri, 13 Jun 2025, at 3:57 AM, Brotman, Alex wrote: > > 1) I am okay with stating the header removal as a MUST. Though, I'd like to see some consensus. Or I'm at least interested if someone has an argument against removing those headers on an inbound MTA. > > For example, if the headers were covered by ARC on a forwarded message, is that okay? Are they potentially usable? (I wouldn't think so, for a few reasons) > > -- > Alex Brotman > Sr. Engineer, Anti-Abuse & Messaging Policy > Comcast > > > -----Original Message----- > From: Andrew C Aitchison > Sent: Wednesday, June 11, 2025 7:11 AM > To: bimi@ietf.org > Subject: [Bimi] BIMI headers that an MTA must delete > > > I was re-reading the list archive and came across this from May 2024: > AFAIK No MUAs actually implement it using those two headers, feel to > list any. Current implementations seem to use Authentication-Results (or > equivalent) but usable implementations seem to be limited to a specific > pairings of MTA+MUA. This is in theory because some MTAs might be > grossly insecure and do not remove/replace the AR header properly. (But > at that point I'd say the MUA has bigger problems than forged BIMI.) https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/bimi/zSwqK5yyTuEYnuumvUv1NZEqSQs/__;!!CQl3mcHX2A!F1zZz00yUT2zfCQ6_o74CUCccPSD-wlr69QVyNkf_6qVmCch3YU3Ssoh6avq5TT-BTtMYDzVHVEjqnjiNNtmdoIALj5e$ > > 1. Could the draft-RFC be updated to say that the AR header MUST be removed/replaced, as well as (instead of ?) BIMI-Location, BIMI-Indicator or BIMI-Logo-Preference ? > > > https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-brotman-ietf-bimi-guidance__;!!CQl3mcHX2A!F1zZz00yUT2zfCQ6_o74CUCccPSD-wlr69QVyNkf_6qVmCch3YU3Ssoh6avq5TT-BTtMYDzVHVEjqnjiNNtmdkRwngxQ$ > 5.2.1 does suggest removing all BIMI-* headers but not Authentication-Results, upon receipt - but only a "should" not a "MUST" or "must". > > https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-brand-indicators-for-message-identification__;!!CQl3mcHX2A!F1zZz00yUT2zfCQ6_o74CUCccPSD-wlr69QVyNkf_6qVmCch3YU3Ssoh6avq5TT-BTtMYDzVHVEjqnjiNNtmdocqA1cJ$ > only disusses removing BIMI-Location, BIMI-Indicator and BIMI-Logo-Preference > > 2. You cannot really blame a non-BIMI-supporting MTA for *not* removing any of these headers. Calling them "grossly insecure" is not appropriate. > If you wish them to remove unsafe incoming headers, please make the > (draft) standard clear on what they MUST do. > > It is *not* satisfactory that we have a protocol currently in use across the internet whose standard says that certain things MUST be done *by third parties* to make it secure, but does not accurately say what these things are. > > -- > Andrew C. Aitchison Kendal, UK > andrew@aitchison.me.uk > > -- > bimi mailing list -- bimi@ietf.org > To unsubscribe send an email to bimi-leave@ietf.org > -- > bimi mailing list -- bimi@ietf.org > To unsubscribe send an email to bimi-leave@ietf.org > -- Marc Bradshaw marcbradshaw.net --536d779f780244f4ab17652642a390a3 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
I would not = state that the AR header MUST be removed, this would depend on how the r= eceiving system consumes them. I would expect there to be matching on th= e authserv id, and that inbound ARs with conflicting authserv IDs would = be removed or renamed. This is all outside of the scope of BIMI.
I would support stating that the BIMI-* headers MUST be removed or re= named on ingress.



On Fri, 13 Jun 2025, at 3:57 AM, Brotman, Alex wrote:

1) I am okay with= stating the header removal as a MUST.  Though, I'd like to see som= e consensus.  Or I'm at least interested if someone has an argument= against removing those headers on an inbound MTA.

<= div>For example, if the headers were covered by ARC on a forwarded messa= ge, is that okay?  Are they potentially usable? (I wouldn't think s= o, for a few reasons)

-- 
Alex B= rotman
Sr. Engineer, Anti-Abuse & Messaging Policy
Comcast


-----Original Message= -----
From: Andrew C Aitchison <andrew@aitchison.me.uk> 
Sent: Wedn= esday, June 11, 2025 7:11 AM
Subject: [Bimi] BIMI headers that a= n MTA must delete


I was re-readi= ng the list archive and came across this from May 2024:
 =   AFAIK No MUAs actually implement it using those two headers, feel= to
   list any. Current implementations seem to use= Authentication-Results (or
   equivalent) but usabl= e implementations seem to be limited to a specific
  = ; pairings of MTA+MUA. This is in theory because some MTAs might be
   grossly insecure and do not remove/replace the AR hea= der properly. (But

=
1. Could the draft-RFC be updated to say that the AR header MUST be= removed/replaced, as well as (instead of ?) BIMI-Location, BIMI-Indicat= or or BIMI-Logo-Preference ?


https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft= -brotman-ietf-bimi-guidance__;!!CQl3mcHX2A!F1zZz00yUT2zfCQ6_o74CUCccPSD-= wlr69QVyNkf_6qVmCch3YU3Ssoh6avq5TT-BTtMYDzVHVEjqnjiNNtmdkRwngxQ$
5.2.1 does suggest removing all BIMI-* headers but not Authentica= tion-Results, upon receipt - but only a "should" not a "MUST" or "must".=

on= ly disusses removing BIMI-Location, BIMI-Indicator and BIMI-Logo-Prefere= nce

2. You cannot really blame a non-BIMI-suppo= rting MTA for *not* removing any of these headers. Calling them "grossly= insecure" is not appropriate.
If you wish them to remove unsa= fe incoming headers, please make the
(draft) standard clear on= what they MUST do.

It is *not* satisfactory th= at we have a protocol currently in use across the internet whose standar= d says that certain things MUST be done *by third parties* to make it se= cure, but does not accurately say what these things are.

<= /div>
-- 
Andrew C. Aitchison    =             =       Kendal, UK
   &n= bsp;           &n= bsp;    an= drew@aitchison.me.uk

--
bimi mail= ing list -- bimi@ietf.org
To unsubscribe send an email to bimi-leave@ietf.org
-- 
bimi mail= ing list -- bimi@ietf.org
To unsubscribe send an email to bimi-leave@ietf.org

=
--
<= /tr>

  Marc Bradshaw
 &nb= sp;marcbradshaw.net


--536d779f780244f4ab17652642a390a3--