Re: [Bimi] MUA Evaluation of BIMI

[Ken O'Driscoll <[e-mail]>]

> -----Original Message-----
> From: Dave Crocker <[e-mail]>
> Sent: Tuesday 15 March 2022 16:36
> To: Ken O'Driscoll <[e-mail]>; Trent Adams
> <[e-mail]>; Brotman, Alex <[e-mail]>
> Cc: [e-mail]
> Subject: Re: [Bimi] MUA Evaluation of BIMI
> 
[...snip...]
> 
> 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.

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.

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