Re: [Bimi] MUA Evaluation of BIMI

[Trent Adams <[e-mail]>]

Yeah, I could get behind some sort of cascading validation model like that.  Basically, if an MUA wants to display BIMI logos, they need to verify that the underlying AuthN-Results are applicable.

I personally believe that if mailbox providers are going to update their code (which would be required for either ARC or a modified DKIM solution), I'd much prefer that they use ARC (since it has much broader applicability and more long-term bang for the buck).  But if we narrow the focus to BIMI… yeah… as long as the MUA can identify and validate the applicable AuthN-Results, that's better then MUAs just guessing.

I'm just nervous that a message will include a handful of AuthN-Results headers (in random order), and an MUA will be left to guess which is applicable.  So, yeah… a cascading "if this works, great, if not try this, but if not… do nothing" seems like a reasonable approach.

My $0.02,
Trent


From: bimi <[e-mail]> on behalf of "Brotman, Alex" <Alex_Brotman=[e-mail]>
Date: Wednesday, March 16, 2022 at 9:25 AM
To: "[e-mail]" <[e-mail]>, Ken O'Driscoll <ken=[e-mail]>, Stephen Farrell <[e-mail]>, Jakub Olexa <jakub=[e-mail]>
Cc: "[e-mail]" <[e-mail]>
Subject: Re: [Bimi] MUA Evaluation of BIMI

So it seems clear we need some way to validate the results of the MTA authentication evaluation, presuming they divulge those results into the headers of the message. Trent suggested ARC, and while that should do that, it may not be ideal given


So it seems clear we need some way to validate the results of the MTA authentication evaluation, presuming they divulge those results into the headers of the message.  Trent suggested ARC, and while that should do that, it may not be ideal given adoption, and perhaps creating an additional barrier.



What if we were instead to say something along the lines of:



The MUA MAY decide to evaluate the authentication results of a message, and then optionally display the associated logo as appropriate.  In order to do so, the MUA MUST be able to validate a header containing the authentication results in the same message. It SHOULD be preferred to utilize the ARC-Results head where possible, and a fallback MAY be a DKIM signature created by the receiving system where the d= MUST be the same as the 5321 Domain used for the recipient and MUST cover the Authentication-Results header created by the receiving system.



My thought is that DKIM is more widely understood and deployed than ARC, and if we need some method to ensure the validity of those MTA-provided results, they should be equally useful.  That needs wordsmithing, but thought I'd pass it along.



--

Alex Brotman

Sr. Engineer, Anti-Abuse & Messaging Policy

Comcast



> -----Original Message-----

> From: bimi <[e-mail]> On Behalf Of Dave Crocker

> Sent: Tuesday, March 15, 2022 4:34 PM

> To: Ken O'Driscoll <ken=[e-mail]>; Stephen

> Farrell <[e-mail]>; Jakub Olexa

> <jakub=[e-mail]>

> Cc: [e-mail]

> Subject: Re: [Bimi] MUA Evaluation of BIMI

>

> On 3/15/2022 1:27 PM, Ken O'Driscoll wrote:

> > Independent MUAs are going to implement BIMI regardless. Telling them

> > that they can't in the specification isn't the solution. All that'll

> > ends up doing is turn BIMI into a Gravatar.

> >

> > The spec. needs to articulate how they can do so, what the risks are,

> > and how to do it properly.

>

>

> Exactly.

>

> If an email feature for an end user cannot be implemented in their

> independent MUA, that's a pretty serious limitation, at Internet scale.

>

> If there are basic requirements to the distributed implementation that limit

> what portion is 'allowed' in the MUA, that needs to be justified and

> documented clearly.

>

> d/

>

> ps. fears about encouraging/discouraging something, other than through the

> usual normative language, moves into the realm of mass psychology, which is

> considerably beyond the scope of most Internet technical specification

> groups' competence.

>

> --

> Dave Crocker

> Brandenburg InternetWorking

> bbiw.net

>

> --

> bimi mailing list

> [e-mail]

> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/bimi__

> ;!!CQl3mcHX2A!Vh3DCZZUfdB9r0L7LxwLfQUJ8Muv-p_NmKRRL6tT_S-

> Rwqh4rpLY_lfE2eckcHfbfr6NHrs$



--

bimi mailing list

[e-mail]

https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/bimi__;!!ORgEfCBsr282Fw!oDz0k2osH9b2hnZ1xHiWEsX6_v6CclQDS6l1UIoDxxGDc99vYg-Nr0wZvUk-erXnmysMbo-zJbxUU6LYp4azVUcthzt0jgH0$