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

[Marc Bradshaw <[e-mail]>]

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]> 
> Sent: Wednesday, June 11, 2025 7:11 AM
> To: [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$ 
> 
> 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
>                     [e-mail]
> 
> --
> bimi mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> -- 
> bimi mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> 

--

  Marc Bradshaw
  marcbradshaw.net