[Bimi] Re: BIMI headers that an MTA must delete

["Brotman, Alex" <[e-mail]>]

I did upload a -10 that I hope addresses the "avp" oversight, and also adds a section about handling the headers on an inbound message.

--
Alex Brotman
Sr. Engineer, Anti-Abuse & Messaging Policy
Comcast

From: Marc Bradshaw <marc=[e-mail]>
Sent: Thursday, June 12, 2025 7:31 PM
To: Brotman, Alex <[e-mail]>; Andrew C Aitchison <[e-mail]>; [e-mail]
Subject: Re: [Bimi] Re: BIMI headers that an MTA must delete

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 <[e-mail]<mailto:[e-mail]>>
Sent: Wednesday, June 11, 2025 7:11 AM
To: [e-mail]<mailto:[e-mail]>
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$<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$<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$<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
                    [e-mail]<mailto:[e-mail]>

--
bimi mailing list -- [e-mail]<mailto:[e-mail]>
To unsubscribe send an email to [e-mail]<mailto:[e-mail]>
--
bimi mailing list -- [e-mail]<mailto:[e-mail]>
To unsubscribe send an email to [e-mail]<mailto:[e-mail]>


--
[https://secure.gravatar.com/avatar/b214a020f4eb135ce2a6901d7540bdb1?s=44&d=404]
  Marc Bradshaw
  marcbradshaw.net<https://urldefense.com/v3/__http:/marcbradshaw.net/__;!!CQl3mcHX2A!B2Dwe2dRWNEIQia9EDg5Aw5ECAtwwaGxx-OqOXVkIpW2cVgdCFz_kkU7FqFnBqYmtdmt2jVoISA5aJMyFMS3MEXWCGvrU1NQF2Q$>