Subject: [Bimi] MUA Evaluation of BIMI

From: Trent Adams <[email-masked]>
Date: Sat, 12 Mar 2022 00:35:27 +0000

I'm looking for clarity about what folks think about whether or not MUAs alone can evaluate BIMI (or be discouraged from doing so).  Either way… I think the next draft of the specification needs to be more clear (as its currently ambiguous).

To provide context… most of the MUAs supporting BIMI today are operated by major mailbox providers that control their clients.  That means that the MUAs (whether they're desktop, mobile, or web clients) are designed to inherently trust the MTAs validation of BIMI and the underlying AuthN requirements.  So, this question is really more aimed at addressing the issues of "independent" MUAs (i.e. email clients that are developed by folks without ties to specific mailbox providers)… something like FairEmail<https://email.faircode.eu/>.

On the one hand, it's the MTA that's performing the underlying validation required by BIMI (e.g. SPF, DKIM, and DMARC).  And since the MUA may not have access to the necessary information in order to perform the validations (e.g. SPF), it relies upon the evaluation performed by the MTA.  Without a close coupling between the evaluating MTA and the MUA… perhaps BIMI validation should be discouraged.

On the other hand, even if an independent MUA doesn't have access to the initial conditions available to the MTA, there are signals they can use for BIMI.  For example, perhaps they can forego SPF and only rely upon DKIM (which may survive all the way to the MUA).  So, maybe there's a path there (albeit with diminished returns).

So, that's what I'm wondering about… how can the next draft of the specification be improved to clarify whether MUAs can (or should not) implement BIMI.

Thoughts?

- Trent

--
J. Trent Adams
Director, Ecosystem Security
Proofpoint

[email-masked]
https://www.linkedin.com/in/jtrentadams

---

From: Jakub Olexa <[email-masked]>
Date: Sun, 13 Mar 2022 08:24:17 +0000

Hi Trent,

FairMail does a very good job at checking the Authentication-Result 
headers to make a decision about whether should be displayed or not. MUA 
should be able to take advantage of the Authentication-Result headers 
and do this. Discouraging BIMI would mean limiting adoption.

Jakub Olexa
Founder & CEO
E-mail: [email-masked]
Tel: +420 778 535 877 <tel:+420778535877>

Mailkit - Closing the circle between Deliverability and Engagement 
<https://www.mailkit.com>

On 12.03.2022 0:35, Trent Adams wrote:
>
> I'm looking for clarity about what folks think about whether or not 
> MUAs alone can evaluate BIMI (or be discouraged from doing so).  
> Either way… I think the next draft of the specification needs to be 
> more clear (as its currently ambiguous).
>
> To provide context… most of the MUAs supporting BIMI today are 
> operated by major mailbox providers that control their clients.  That 
> means that the MUAs (whether they're desktop, mobile, or web clients) 
> are designed to inherently trust the MTAs validation of BIMI and the 
> underlying AuthN requirements.  So, this question is really more aimed 
> at addressing the issues of "independent" MUAs (i.e. email clients 
> that are developed by folks without ties to specific mailbox 
> providers)… something like FairEmail <https://email.faircode.eu/>.
>
> On the one hand, it's the MTA that's performing the underlying 
> validation required by BIMI (e.g. SPF, DKIM, and DMARC).  And since 
> the MUA may not have access to the necessary information in order to 
> perform the validations (e.g. SPF), it relies upon the evaluation 
> performed by the MTA.  Without a close coupling between the evaluating 
> MTA and the MUA… perhaps BIMI validation should be discouraged.
>
> On the other hand, even if an independent MUA doesn't have access to 
> the initial conditions available to the MTA, there are signals they 
> can use for BIMI.  For example, perhaps they can forego SPF and only 
> rely upon DKIM (which may survive all the way to the MUA).  So, maybe 
> there's a path there (albeit with diminished returns).
>
> So, that's what I'm wondering about… how can the next draft of the 
> specification be improved to clarify whether MUAs can (or should not) 
> implement BIMI.
>
> Thoughts?
>
> - Trent
>
> -- 
>
> *J. Trent Adams*
>
> /Director, Ecosystem Security/
>
> *Proofpoint*
>
> [email-masked]
>

---

From: Ken O'Driscoll <[email-masked]>
Date: Mon, 14 Mar 2022 15:39:17 +0000

It’s really up to the user of the MUA to determine whether or not to trust upstream authentication headers. There are already plugins for the likes Roundcube and Thunderbird that are parsing the current AR headers.

I think the specification would need to note the privacy considerations associated with independent MUA-level support for BIMI. Namely, the remote image loading will not be cached like it is with mailbox providers, so it could be abused to disclose when a recipient opens a message.

Ken.

From: bimi <[email-masked]> On Behalf Of Trent Adams
Sent: Saturday 12 March 2022 00:35
To: [email-masked]
Subject: [Bimi] MUA Evaluation of BIMI

Thoughts?

- Trent

[email-masked]<mailto:[email-masked]>
https://www.linkedin.com/in/jtrentadams

---

From: Dave Crocker <[email-masked]>
Date: Mon, 14 Mar 2022 08:50:09 -0700

On 3/14/2022 8:39 AM, Ken O'Driscoll wrote:
> It’s really up to the user of the MUA to determine whether or not to 
> trust upstream authentication headers. There are already plugins for the 
> likes Roundcube and Thunderbird that are parsing the current AR headers.

yes, but...

As a matter of systems design,

   0) the average use is never realistically in a position to make that 
assessment

   1) the fact that A-R is an integral component of the trust model 
needs to be clearly explained, including the factors affecting that 
trust, and the meaningful, real-world threats to consider

   2) an assessment of reasonable, real-world assignments of trust would 
show serious due diligence and give meaningful guidance; that is, look 
at common operational arrangements and suggest reasonable operational 
modes for BIMI use.

In other words, as an end-to-end service, BIMI really should NOT simply 
defer the question of MTA/MDA/MUA interaction as trust as something left 
to "the user of the MUA to determine".

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Ken O'Driscoll <[email-masked]>
Date: Mon, 14 Mar 2022 16:27:42 +0000

> -----Original Message-----
> From: Dave Crocker <[email-masked]>
> Sent: Monday 14 March 2022 15:50
> To: Ken O'Driscoll <[email-masked]>; Trent Adams
> <[email-masked]>
> Cc: [email-masked]
> Subject: Re: [Bimi] MUA Evaluation of BIMI
>
[...snip...]
> to "the user of the MUA to determine".

I completely agree and didn't intend to appear to advocate for a free for all.

If people begin to see value in supporting BIMI at the MUA level, then they will do so with or without the endorsement of the specification. However, if the spec. clearly articulates implementation considerations and risks, then it can only be a good thing.

In particular, the vendors of third-party webmail software that many ISPs white label, would likely benefit from clear published guidance instead of trying to guess best practice.

Ken.

---

From: "John Levine" <[email-masked]>
Date: 14 Mar 2022 12:42:52 -0400

>to "the user of the MUA to determine".

Since BIMI is about marketing, if people want to show logos, what the heck, why not.

If the question is that they might show logos by mistake on malicious mail, why is that
mail even in the inbox?  The MUA is way too late for that kind of defense.

R's,
John

---

From: Dave Crocker <[email-masked]>
Date: Mon, 14 Mar 2022 10:57:53 -0700

> If people begin to see value in supporting BIMI at the MUA level, then they will do so with or without the endorsement of the specification. However, if the spec. clearly articulates implementation…

I'd class it more than merely a Good Thing.

Given that BIMI relies on underlying, security-related protocols, and 
BIMI itself makes validation efforts, I'd class a serious risk, threat, 
etc. analysis -- and guidance -- to be essential, professional due 
diligence.

It's not just that people 'might choose' to do a particular 
configuration, it's that the nature of the service is end-to-end and all 
of the mechanisms can easily be placed in those end points.  So when 
someone puts an essential component somewhere else, THAT is when there 
should be concern.

In other words, BIMI (and DMARC with DKIM) all work perfectly well in 
the MUA.  So should BIMI.  And when a component is placed elsewhere -- 
as is both reasonable and likely -- then it needs to be accounted for 
during design and specification, not later when it finally starts 
getting deployed.

d/

---

From: "Brotman, Alex" <[email-masked]>
Date: Mon, 14 Mar 2022 20:55:23 +0000

> It’s really up to the user of the MUA to determine whether or not to trust upstream authentication headers. There are already plugins for the likes Roundcube and Thunderbird that are parsing the cu…

I feel like an item that needs to be considered is that if you’re to rely on these headers, you need to have a reasonable assurance they came from the MBP for which the message was intended.  Do we need notes to describe how it is that the MUA is meant to evaluate that header and its origin?  Or is that beyond our scope?

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

---

From: Richard Clayton <[email-masked]>
Date: Mon, 14 Mar 2022 16:34:20 +0000

In message <[email-masked]>, Dave
Crocker <[email-masked]> writes

>to "the user of the MUA to determine".

there is of course a similar trust issue relating to DNSSEC ... drawing
on the literature there would be helpful I think 

- -- 
richard                                                   Richard Clayton

Those who would give up essential Liberty, to purchase a little temporary 
Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755

---

From: Trent Adams <[email-masked]>
Date: Tue, 15 Mar 2022 16:14:45 +0000

OK… what if we start from the premise that an MUA *MAY* evaluate BIMI, but in order to do is it *MUST* be able to trust the Authentication-Results header supplied by the mailbox provider (read: it there's no trusted A-R header, the MUA *MUST NOT* display the BIMI logo)…

Given that… What if the specification calls for the mailbox provider performing BIMI validation to ARC sign the messages they receive?  Would that be a useful way to preserve the A-R results such that the MUA can verify them?

Curious,
Trent

From: "Brotman, Alex" <Alex_Brotman=[email-masked]>
Date: Monday, March 14, 2022 at 2:56 PM
To: Ken O'Driscoll <[email-masked]>, Trent Adams <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: RE: MUA Evaluation of BIMI

---

From: Ken O'Driscoll <[email-masked]>
Date: Tue, 15 Mar 2022 16:28:38 +0000

I don’t think there should be any recommendations that an MUA carries out any independent validation or “double-checking” etc. It’s the wrong place for the operation. If the upstream MTA is lying then all bets are off anyway.

Ken.

From: Trent Adams <[email-masked]>
Sent: Tuesday 15 March 2022 16:15
To: Brotman, Alex <Alex_Brotman=[email-masked]>; Ken O'Driscoll <[email-masked]>
Cc: [email-masked]
Subject: Re: MUA Evaluation of BIMI

Curious,
Trent

From: "Brotman, Alex" <Alex_Brotman=[email-masked]<mailto:Alex_Brotman=[email-masked]>>
Date: Monday, March 14, 2022 at 2:56 PM
To: Ken O'Driscoll <[email-masked]<mailto:[email-masked]>>, Trent Adams <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: MUA Evaluation of BIMI

---

From: Dave Crocker <[email-masked]>
Date: Tue, 15 Mar 2022 09:36:04 -0700

On 3/15/2022 9:28 AM, Ken O'Driscoll wrote:
> I don’t think there should be any recommendations that an MUA carries 
> out any independent validation or “double-checking” etc. It’s the wrong 
> place for the operation. If the upstream MTA is lying then all bets are 
> off anyway.

DKIM can work fine in an MUA-based validation.  Obviously there is 
nothing wrong with doing validation at the MTA/MDA level, but the 
architecture is, really, an end-to-end design, which means supportable 
in the recipient's MUA.  A DMARC that relies on DKIM rather than SPF 
also does.

So, not, it is not (necessarily) the wrong place for the operation.

As for the receiving MTA lying, turn the issue around:  how can the MUA 
know that the field came from that specific, well-behaved, thoroughly 
compliant MDA or MTA.

Broadly, how is the chain of trust established sufficiently for the MUA 
to know that the A-R header field is to be trusted?

d/

---

From: Ken O'Driscoll <[email-masked]>
Date: Tue, 15 Mar 2022 18:00:08 +0000

> Sent: Tuesday 15 March 2022 16:36
> <[email-masked]>; Brotman, Alex <[email-masked]>
> Cc: [email-masked]
[...snip...]
> So, not, it is not (necessarily) the wrong place for the operation.

Sure, DKIM can be implemented in an MUA, but the accuracy of the results is architecture dependent. For example, if the architecture modifies inbound messages after DKIM is verified (e.g., puts an "External message" warning in) then while the A-R header is correct, the MUA-level DKIM validation will give a different answer. The MUA may correctly validate DKIM but that does not fully inform the user of anything useful regarding message authentication.

So yes, it's possible but with too many caveats to be useful to recommend in general, or in a specification. 

I believe the same goes, to a lesser degree, for MUA-level ARC validation of A-Rs. For example, there still isn't a clear path to determine if a given ARC header set is to be trusted. So, an MUA would have to implement some external mechanism to achieve that. Or the MUA could just trust the upstream MTA, which negates the need for ARC signing A-R headers in the first place.

> to know that the A-R header field is to be trusted?

I'm actually not sure that they should be programmatically trusted by an MUA because there isn't an established reliable low-cost mechanism to do so. By that I mean, for example, even if the ARC trust issue was solved tomorrow, I doubt that a mobile phone based MUA is going undertake the resource cost of reliability implementing ARC validation for each message.

MUA level trust in headers should be based on user/implementor awareness of its limitations and risks. A spec. can do that. A spec. could even say that a TLS connection between the MUA and MTA is required. If you want chain of trust at MUA level, then use a PKI-based solution.

I believe the goal should be to avoid as much as possible some future MTA-level implementation with the hypothetical "Always_show_BIMI_logo_regardless = true;" configuration option. I think that best way to work towards that goal is for the specification to clearly articulate the conditions, limitations, and considerations for implementing BIMI at MUA level.

Ken.

---

From: Dave Crocker <[email-masked]>
Date: Tue, 15 Mar 2022 11:14:34 -0700

On 3/15/2022 11:00 AM, Ken O'Driscoll wrote:
> Sure, DKIM can be implemented in an MUA, but the accuracy of the
> results is architecture dependent. For example, if the architecture
> modifies inbound messages after DKIM is verified (e.g., puts an
> "External message" warning in) then while the A-R header is correct,
> the MUA-level DKIM validation will give a different answer. The MUA
> may correctly validate DKIM but that does not fully inform the user
> of anything useful regarding message authentication.
> 
> So yes, it's possible but with too many caveats to be useful to
> recommend in general, or in a specification.

1. the concern applies to all components that touch the message along 
the path.  Within a recipient's enterprise system, the odds of this 
being a problem might be higher, but that simply points to the need for 
clarity about end-to-end trust issues with BIMI use; it also turns out 
to play into the next, larger point...

2. Just as the enterprise might mess up the DKIM signature, it might 
create problems with an A-R field.

> I believe the same goes, to a lesser degree, for MUA-level ARC

Sorry to have left that off.  As I recall, it, too, is an end-to-end 
architecture that can reasonably be implemented in the MUA.  And yes, 
handlers along the path to it can mess up the ARC data.

>> As for the receiving MTA lying, turn the issue around:  how can the
>> MUA know that the field came from that specific, well-behaved,
>> thoroughly compliant MDA or MTA.
>> 
>> Broadly, how is the chain of trust established sufficiently for the
>> MUA to know that the A-R header field is to be trusted?
> 
> I'm actually not sure that they should be programmatically trusted by
> an MUA because there isn't an established reliable low-cost mechanism
> to do so. 

I think you've just implied that an independent MUA should never display 
a BIMI icon, since it can't be trusted...

By that I mean, for example, even if the ARC trust issue
> was solved tomorrow, I doubt that a mobile phone based MUA is going
> undertake the resource cost of reliability implementing ARC
> validation for each message.

I was making an architectural point, which means it is independent of 
implementation specifics.

You are making a reasonable point, but it is about a specific 
implementation/use concern  (And given the power and connectivity of 
typical smartphones these days, uhhh...)

> MUA level trust in headers should be based on user/implementor
> awareness of its limitations and risks. A spec. can do that. A spec.
> could even say that a TLS connection between the MUA and MTA is
> required. If you want chain of trust at MUA level, then use a
> PKI-based solution.

This goes back to the original point that this issue needs due diligence 
and documentation.

> I believe the goal should be to avoid as much as possible some future
> MTA-level implementation with the hypothetical
> "Always_show_BIMI_logo_regardless = true;" configuration option. I
> think that best way to work towards that goal is for the
> specification to clearly articulate the conditions, limitations, and
> considerations for implementing BIMI at MUA level.

+1

d/

---

From: Trent Adams <[email-masked]>
Date: Tue, 15 Mar 2022 18:32:37 +0000

These are all good points… and knowing that there's no clear win here, what if the specification identified a pattern along the lines of:

  1.  If the MUA can validate the DKIM signature in the message, and DMARC alignment passes, it can validate BIMI and take the appropriate steps to display the logo.  Sure, it's a long shot, but it could happen.
  2.  If DKIM validation fails, the MUA looks for the most recent ARC signature block, and if it's from the mailbox provider (e.g. "gmail.com"), the MUA may use the signed AuthN-Results on the way to validating BIMI.
  3.  If there is no identifiable ARC signature from which the MUA can extract verified AuthN-Results from the mailbox provider, the MUA may (at their peril) cook up local magic to identify what they believe to be reasonable AuthN-Results to use for BIMI validation (though, this is discouraged within the Security Considerations section).

I know… this is all very algorithmic… and it side-steps the point about resources of constrained devices (but since there's at least one mobile client doing it today, I guess it's not impossible)… but it would provide some guidance to address the question of how independent MUAs might be able to perform BIMI validation.

Otherwise… if we really don't think it's a good idea to allow anyone other than the MTA validating SPF+DKIM+DMARC to evaluate BIMI… then we should update the spec to specifically call that out.  It's the ambiguity hole we should try to address (even if just for now, knowing we can think up better ideas over time).

More thoughts,
Trent

From: Dave Crocker <[email-masked]>
Organization: Brandenburg InternetWorking
Date: Tuesday, March 15, 2022 at 12:14 PM
To: Ken O'Driscoll <ken=[email-masked]>, Trent Adams <[email-masked]>, "Brotman, Alex" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [Bimi] MUA Evaluation of BIMI

On 3/15/2022 11:00 AM, Ken O'Driscoll wrote: >> So, not, it is not (necessarily) the wrong place for the >> operation. > > Sure, DKIM can be implemented in an MUA, but the accuracy of the > results is architecture dependent.

On 3/15/2022 11:00 AM, Ken O'Driscoll wrote:

>> So, not, it is not (necessarily) the wrong place for the

>> operation.

and documentation.

+1

d/

--

Dave Crocker

bbiw.net

---

From: Jakub Olexa <[email-masked]>
Date: Tue, 15 Mar 2022 18:45:20 +0000

Hi Trent,

my concern with this approach is that it would essentially prevent MUAs 
from implementing BIMI support.

a) ARC would essentially become a requirement for BIMI outside the BIMI 
standard itself
b) MBPs would have to implement ARC, which would result in reduced 
support for BIMI
c) MUAs would have to do way more complex checks then they do at the 
moment... involving DNS lookups, signature validation etc. - this could 
be a problem when logos are displayed in the message list

For example when using Fairmail on our mailserver via IMAP I'm getting 
all the info about authentication from the headers added by our MTA and 
FairMail will display BIMI where available. We haven't had to do any 
changes to our MTA to get BIMI working. This will most likely apply to a 
large number of mail servers. Having an ARC requirement would break 
it... and for what good?

Jakub Olexa
Founder & CEO

On 15.03.2022 16:14, Trent Adams wrote:
>
> OK… what if we start from the premise that an MUA **MAY** evaluate 
> BIMI, but in order to do is it **MUST** be able to trust the 
> Authentication-Results header supplied by the mailbox provider (read: 
> it there's no trusted A-R header, the MUA **MUST NOT** display the 
> BIMI logo)…
>
> Given that… What if the specification calls for the mailbox provider 
> performing BIMI validation to ARC sign the messages they receive? 
>  Would that be a useful way to preserve the A-R results such that the 
> MUA can verify them?
>
> Curious,
>
> Trent
>
> *From: *"Brotman, Alex" <Alex_Brotman=[email-masked]>
> *Date: *Monday, March 14, 2022 at 2:56 PM
> *To: *Ken O'Driscoll <[email-masked]>, Trent Adams 
> <[email-masked]>
> *Cc: *"[email-masked]" <[email-masked]>
> *Subject: *RE: MUA Evaluation of BIMI
>
> > It’s really up to the user of the MUA to determine whether or not to trust upstream 
> authentication headers. There are already plugins for the likes 
> Roundcube and Thunderbird that are parsing the current AR headers. ‍ ‍ 
> 
>
> > It’s really up to the user of the MUA to determine whether or not to trust upstream authentication headers. 
> There are already plugins for the likes Roundcube and Thunderbird that 
> are parsing the current AR headers.
>
> I feel like an item that needs to be considered is that if you’re to 
> rely on these headers, you need to have a reasonable assurance they 
> came from the MBP for which the message was intended.  Do we need 
> notes to describe how it is that the MUA is meant to evaluate that 
> header and its origin?  Or is that beyond our scope?
>
> --
>
> Alex Brotman
>

---

From: Trent Adams <[email-masked]>
Date: Tue, 15 Mar 2022 18:50:11 +0000

Right… and if I understand correctly, FairMail is using hard-coded heuristics to determine the AuthN-Results based on known formatting (e.g. it knows what the header looks like in Gmail and uses it… otherwise, it's ignored).

Am I right about that? … or is Marcel doing something more clever?

Curious,
Trent

From: bimi <[email-masked]> on behalf of Jakub Olexa <jakub=[email-masked]>
Organization: Mailkit
Date: Tuesday, March 15, 2022 at 12:46 PM
To: "[email-masked]" <[email-masked]>
Subject: Re: [Bimi] MUA Evaluation of BIMI

Hi Trent, my concern with this approach is that it would essentially prevent MUAs from implementing BIMI support. a) ARC would essentially become a requirement for BIMI outside the BIMI standard itself 

Hi Trent,

my concern with this approach is that it would essentially prevent MUAs from implementing BIMI support.

a) ARC would essentially become a requirement for BIMI outside the BIMI standard itself
b) MBPs would have to implement ARC, which would result in reduced support for BIMI
c) MUAs would have to do way more complex checks then they do at the moment... involving DNS lookups, signature validation etc. - this could be a problem when logos are displayed in the message list

For example when using Fairmail on our mailserver via IMAP I'm getting all the info about authentication from the headers added by our MTA and FairMail will display BIMI where available. We haven't had to do any changes to our MTA to get BIMI working. This will most likely apply to a large number of mail servers. Having an ARC requirement would break it... and for what good?

Jakub Olexa
Founder & CEO
E-mail: [email-masked]<mailto:[email-masked]>
Tel: +420 778 535 877<tel:+420778535877>

Mailkit - Closing the circle between Deliverability and Engagement<https://urldefense.com/v3/__https:/www.mailkit.com__;!!ORgEfCBsr282Fw!vHS66phTBR4sfDK7OTpaYnHLf44Jx5761830ySlAeeozI6Dl_Zx-C7nZko8cxEahGMs_D8dr6GH8Qox7x4RHzIAFSoCmrL__$>
On 15.03.2022 16:14, Trent Adams wrote:

Curious,
Trent

From: "Brotman, Alex" <Alex_Brotman=[email-masked]><mailto:Alex_Brotman=[email-masked]>
Date: Monday, March 14, 2022 at 2:56 PM
To: Ken O'Driscoll <[email-masked]><mailto:[email-masked]>, Trent Adams <[email-masked]><mailto:[email-masked]>
Cc: "[email-masked]"<mailto:[email-masked]> <[email-masked]><mailto:[email-masked]>
Subject: RE: MUA Evaluation of BIMI

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 15 Mar 2022 19:50:44 +0000

Hiya,

> from implementing BIMI support.

Interesting. My concern with Trent's #1 was that it might
encourage MUAs to try!

I think it'd be better to explicitly discourage that.

S.

---

From: Ken O'Driscoll <[email-masked]>
Date: Tue, 15 Mar 2022 20:27:51 +0000

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.

Also, to be sure we're all talking about the same thing - independent MUAs comprises of much more than open source projects and academic add-on efforts. There's a whole industry of white label webmail MUAs that service the global ISP and hosting industry. That's where the utility of BIMI will likely live or die.

Ken.

________________________________
From: bimi <[email-masked]> on behalf of Stephen Farrell <[email-masked]>
Sent: Tuesday 15 March 2022, 19:51
To: Jakub Olexa <jakub=[email-masked]>; [email-masked] <[email-masked]>
Subject: Re: [Bimi] MUA Evaluation of BIMI

Hiya,

S.

---

From: Dave Crocker <[email-masked]>
Date: Tue, 15 Mar 2022 13:33:42 -0700

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.
> 

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.

---

From: "Brotman, Alex" <[email-masked]>
Date: Wed, 16 Mar 2022 15:24:24 +0000

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.

> From: bimi <[email-masked]> On Behalf Of Dave Crocker
> Sent: Tuesday, March 15, 2022 4:34 PM
> To: Ken O'Driscoll <ken=[email-masked]>; Stephen
> Farrell <[email-masked]>; Jakub Olexa
> <jakub=[email-masked]>
> Cc: [email-masked]
> 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
> bimi mailing list
> [email-masked]
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/bimi__
> ;!!CQl3mcHX2A!Vh3DCZZUfdB9r0L7LxwLfQUJ8Muv-p_NmKRRL6tT_S-
> Rwqh4rpLY_lfE2eckcHfbfr6NHrs$

---

From: Trent Adams <[email-masked]>
Date: Wed, 16 Mar 2022 16:15:08 +0000

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 <[email-masked]> on behalf of "Brotman, Alex" <Alex_Brotman=[email-masked]>
Date: Wednesday, March 16, 2022 at 9:25 AM
To: "[email-masked]" <[email-masked]>, Ken O'Driscoll <ken=[email-masked]>, Stephen Farrell <[email-masked]>, Jakub Olexa <jakub=[email-masked]>
Cc: "[email-masked]" <[email-masked]>
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

--

Alex Brotman

Comcast

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

> > and how to do it properly.

--

bimi mailing list

[email-masked]

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

---

From: "John Levine" <[email-masked]>
Date: 16 Mar 2022 14:29:47 -0400

It appears that Brotman, Alex <[email-masked]> said:
>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.

I don't get it.  I can see situations where you believe the topmost A-R in the message and where you don't,
but I don't see how signing it would help, since I can sign my A-R even if I am lying so you have the
exact same situation deciding whether to believe the signer.

This would be a situation where an IMAP server mangles or forges A-R headers but is otherwise
trustworthy.  That seems kind of implausible.

R's,
John

---

From: Trent Adams <[email-masked]>
Date: Thu, 17 Mar 2022 19:20:36 +0000

>From what I can tell, the decision of whether or not an independent MUA should display a BIMI logo reduces to: "can the MUA reliably determine what the mailbox provider states to be the AuthN results of the evaluation they performed."

I don't believe it's about whether or not the MUA trusts the AuthN evaluation performed by the mailbox provider; that ship has sailed by the time the MUA fetches the mail.  If the MUA starts second-guessing the veracity of what the mailbox provider states, all bets are off well beyond the purview of BIMI.

In case it helps get inside my head (and perhaps illuminate my insanity), here's a rough operational flow I think would work:

  1.  First, let's consider the case that would short circuit this entire flow.  If the independent MUA can verify DKIM for the message it fetched from the mailbox provider, it can evaluate DMARC and BIMI without relying on the AuthN-Results from the mailbox provider.  If so, then we can skip ahead and GOTO 8.  Otherwise, that's where the following process kicks in…
  2.  The following assumes that the MUA trusts mail it fetches from the mailbox provider (otherwise… why're they fetching it?).  If the MUA trusts that the mailbox provider is performing the necessary validation/verification/filtering, etc… then the MUA should be able to trust headers inserted by that specific MTA (as long as they can reliably identify them).
  3.  That's not to say that the MUA should trust all the headers… just the ones that can be confirmed as having been put there by the mailbox provider.  Enter ARC, not so much as a "trust the chain" mechanism, but primarily as a method to "identify AuthN-Results inserted by the mailbox provider".
  4.  If the MUA can identify and verify a signed ARC block that includes the AuthN-Results inserted by mailbox provider, the MUA can use it to make determinations related to BIMI.  Presumably, this includes enough information for the MUA to perform the same BIMI evaluation as the MTA would have.
  5.  Regardless of any other AuthN-Results hanging out in the headers (perhaps ones that the mailbox provider neglected to strip out), at least the MUA knows that the AuthN-Results in the signature block inserted by the mailbox provider indicates what their inbound MTA evaluated.
  6.  And sure, there may be other entries in the ARC chain before what the mailbox provider inserted… and perhaps the MUA will only trust valid AuthN-Results within the block inserted by that mailbox provider (i.e. not a full chain).  But the point of this is that the ARC signature block is currently the only way for the MUA to clearly identify the specific AuthN-Results header inserted by the mailbox provider.
  7.  Optionally… if there's no ARC header inserted by the mailbox provider, perhaps there's a special DKIM-like signed AuthN-Reults header (akin to what Alex suggested)… in that case, the MUA finds it, verifies the signature, and then uses it to move forward.
  8.  Whether the AuthN-Results come from directly validating DKIM, the ARC signature block, or a new DKIM-like signed header…  With this information, the MUA can now decide what to do about BIMI… knowing that they're only trusting the mailbox provider from which they fetched the email.

I get that this is all very hand-wavy at the moment… but I hope that by breaking up the process into discreet steps we can identify where the proposal goes off the rails.  Perhaps then we can focus in and address those specific points and run through it again (hopefully getting further down the track with the next iteration).

Once we see a full path… then we can figure out how to update the specification to more effectively clarify the functionality.

Thoughts?

- Trent

From: bimi <[email-masked]> on behalf of John Levine <[email-masked]>
Organization: Taughannock Networks
Date: Wednesday, March 16, 2022 at 12:30 PM
To: "[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [Bimi] MUA Evaluation of BIMI

It appears that Brotman, Alex <[email-masked]> said: >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.

R's,

John

--

bimi mailing list

[email-masked]

https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/bimi__;!!ORgEfCBsr282Fw!sF7Rls7k9AVY7scazu54DZLRLoHEGm8BSBYOgPj2scNTvzzn_7vmp6Iq-D9sEJLg13wBiGGx9fO6pg$

---

From: "John R Levine" <[email-masked]>
Date: 17 Mar 2022 16:13:56 -0400

> I don't believe it's about whether or not the MUA trusts the AuthN evaluation performed by the mailbox provider; that ship has sailed by the time the MUA fetches the mail.  If the MUA starts second…

Well, yeah.  Remember that ARC is also only useful if you generally trust 
the system sending you a message with ARC seals.  The MUA can't tell what 
IP address a message was really sent from so it can't do SPF, and since 
mail systems frequently add tags like "external message" it can't tell if 
DKIM signatures were valid, either.

You can tie yourself in knots here but I really doubt you're going to end 
up with anything better than believe your MTA's A-R or you don't.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

---

From: Dave Crocker <[email-masked]>
Date: Thu, 17 Mar 2022 13:35:21 -0700

> You can tie yourself in knots here but I really doubt you're going to 
> end up with anything better than believe your MTA's A-R or you don't.

This seems to be trust without verification and without any meaningful 
basis for the trust, other than having logged into an IMAP session with 
a mailbox provider.

Since 'users' certainly won't be doing a meaningful assessment, this 
reduces to:  Random MUAs with support for displaying Bimi images must 
use any A-R header field that shows up.

Note that the trust includes having no basis for knowing whether the 
connected servers knows about, or cares about, A-R fields.

d/

---

From: Jakub Olexa <[email-masked]>
Date: Fri, 18 Mar 2022 08:42:29 +0000

I'd say the only thing that would be worth checking is the source of the 
A-R header and host MAY match the server host (which may often not be 
possible) or fallback to the topmost A-R header.

Keep in mind that BIMI is not a trust indicator but just a logo - 
marketing feature rather than security feature. Custom MUA of a hosting 
company may rely on the A-R headers in a different way as it would get 
those from the MTA they have control over then a public MUA that simply 
has to trust that the user chose an imap server for a reason. What's the 
point of questioning the headers authenticity? I do get that it would 
prevent a malicious actor from having a "fake" logo displayed but the 
impact would be very limited.

maybe we could require MUAs to rely on the BIMI-Indicator header added 
by MUA.

Jakub Olexa
Founder & CEO

On 17.03.2022 20:35, Dave Crocker wrote:
> basis for the trust, other than having logged into an IMAP session 
> with a mailbox provider.
>

---

From: Trent Adams <[email-masked]>
Date: Tue, 22 Mar 2022 16:20:08 +0000

It sounds like there's rough consensus around the idea that for an MUA to have any chance at evaluating BIMI, we first need to ensure the MUA can reliably identify the relevant authentication results.  If not, then the MUA can't evaluate BIMI.  And even if the AuthN-Results can be identified, there's the question about whether or not the MUA can rely upon the information.  I suggest we set aside the veracity of the information until after we more fully explore whether we can reliably identify the AuthN-Results first.

Fortunately, there are a couple existing methods for MTAs to convey authentication results to an MUA:

  *   An AuthN-Results header inserted by the mailbox provider (which may include the BIMI-Results).
  *   A signed ARC signature block, which includes the AuthN-Results.

If we first look at the AuthN-Results header, the question is how the MUA can identify the relevant header.  There's no guarantee that there is only one AuthN-Results header in a given email and, if there's more than one, it's not clear which one's applicable (especially as we can't rely on order).  Fortunately, RFC8601 defines a services identifier that might be used.  Unfortunately, the "authserv-id" field is optional (and can be any arbitrary string).  That makes it sub-optimal for an MUA to rely upon it.

Then, if we consider the ARC signature block, it'll include the AuthN-Results, with the added benefit that it requires that the evaluator be identified by a domain (in the "d=" value of the ARC-Seal block).  Unfortunately, the ARC Signing Domain Identifier (SDID) may be difficult for the MUA to match to the mailbox provider and message.

It's also worth noting that even if the evaluator (whether identified via the AuthN-Results header or the ARC signature block) is identified by a domain, there's no guarantee that the domain will match the domain of the recipient… so the MUA may have a hard time matching them up.  For example, when sending to a "@gmail.com" address, the AuthN-Results authserv-id and the associated ARC results SDID are "google.com".  So, absent prior knowledge baked into the MUA to link the two… there's currently no way for the MUA to figure that out.

Even with the limitations… I think we may be able to specify a cascading set of options the MUA can use to identify relevant AuthN-Results from the mailbox provider (along with the associated caveats).  If, after going through the full if-then-else set of options, and the MUA can't reliably identify relevant AuthN-Results… then it can't evaluate BIMI.

The question I'm wondering about now… is what percentage of relevant AuthN-Results can be identified using this process?   Because if the number is vanishingly small (and unlikely to increase), should we stop chasing the solution for MUAs?  If so, then perhaps we fall back to a section that just describes the issues along with a "user beware" message rather than specifying all the different options.

Anyway, before we start talking about the veracity of the AuthN-Results… is there anything I'm missing, or I've misstated?

Progress(?),
Trent

From: bimi <[email-masked]> on behalf of Jakub Olexa <jakub=[email-masked]>
Organization: Mailkit
Date: Friday, March 18, 2022 at 2:43 AM
To: "[email-masked]" <[email-masked]>
Subject: Re: [Bimi] MUA Evaluation of BIMI

I'd say the only thing that would be worth checking is the source of the A-R header and host MAY match the server host (which may often not be possible) or fallback to the topmost A-R header. Keep in mind that BIMI is not a trust indicator

I'd say the only thing that would be worth checking is the source of the A-R header and host MAY match the server host (which may often not be possible) or fallback to the topmost A-R header.

Keep in mind that BIMI is not a trust indicator but just a logo - marketing feature rather than security feature. Custom MUA of a hosting company may rely on the A-R headers in a different way as it would get those from the MTA they have control over then a public MUA that simply has to trust that the user chose an imap server for a reason. What's the point of questioning the headers authenticity? I do get that it would prevent a malicious actor from having a "fake" logo displayed but the impact would be very limited.

maybe we could require MUAs to rely on the BIMI-Indicator header added by MUA.

Jakub Olexa
Founder & CEO

Mailkit - Closing the circle between Deliverability and Engagement<https://urldefense.com/v3/__https:/www.mailkit.com__;!!ORgEfCBsr282Fw!vffTF121WWRZp3c6MeAaSmZYDkpQYWTA2tLEoWsZ49u2F-7fHnr2CSIcf06VWlRahB7B9jGfL5wEhxp-41Dzl5gIBCszefZs$>
On 17.03.2022 20:35, Dave Crocker wrote:

You can tie yourself in knots here but I really doubt you're going to end up with anything better than believe your MTA's A-R or you don't.

This seems to be trust without verification and without any meaningful basis for the trust, other than having logged into an IMAP session with a mailbox provider.

Since 'users' certainly won't be doing a meaningful assessment, this reduces to:  Random MUAs with support for displaying Bimi images must use any A-R header field that shows up.

Note that the trust includes having no basis for knowing whether the connected servers knows about, or cares about, A-R fields.

d/